I'm pleased to say that, albeit not perfectly implemented, I have managed to turn #Aerodox into the project it was always supposed to be by getting it to work on more than one PC.  #Aerodox 's layout is based on Ergodox but it's circuitry is based on the #Redox keyboard 's wireless version. This was deliberately because Mattia Dal Ben had done a great job implementing a wireless keyboard and also documenting it. The internals of the wireless Redox were a clear analogue that showed me what I wanted probably lay down that path. 

Unfortunately, it would need a receiver on each PC, as well as a Gazell protocol channel hopping scheme that you would need to switch over on both halves of the keyboard. After making the changes to boost the voltage on the motherboards, I was using Aerodox daily and knew I wanted to make a move to use it on my other PC(s). But one thing was niggling me - someone had managed to get bluetooth working on the Mitosis, the keyboard that I think inspired the Redox wireless and they now had a small keyboard that had a Gazell link between the halves and bluetooth from one half back to the PC. 

The icing on the cake for me was that they were able to switch between 3 different PCs using the bluetooth. For the last two days I have been trying adapt the Bluetosis code to work on #Aerodox and tonight I finally got it working. I'm so chuffed I can switch between my two main PCs with a press of this little button:

There are kinks to iron out. Firstly, I had to ditch the way timer interrupts and debouncing is done in the Redox way and I think I have taken a hit on responsiveness to key presses on the right (bluetooth/Gazell host) half. But I'm optimistic that I'll be able to tweak that. For example, there is an 8Hz Gazell message transmission that the left half sends until it goes to sleep after 500ms and I think the new scheme could potentially do away with that, freeing up buffer-transfers on the host side.

Other things that other people may not like is that although the keymaps are qmk-like, nothing is running qmk any more (it was on the pro-micro connected to / built into the Redox wireless receiver). I don't care as I can press all the keys I want to!

Other than optimising the responsiveness, what else is there to do with Aerodox? Well this recent foray has given me more confidence to navigate Nordic chips and tools, and with ZMK up-and-coming, perhaps we'll see an NRF52 version of #Aerodox one day. 

Also, you can't go your whole life wondering if the first split ortholinear ergo key layout you picked was the best one, when there are so many to try...

Well, this is overdue and short. But one of the biggest failings of Aerodox was an extremely poor range to the PC, needing to press a key several times before it would register and sometimes pressing the key resulted in multiple keystrokes on screen.

A long and winding thread at github where we got distracted by Gazell channel hopping configuration settings ended in me testing the difference between a solid 3.3V supply and the 2x AA cells I was using. Bear in mind the "spec" for the NRF51822 modules we're using says they go down to 2V. The difference was night and day.

The nice thing about making #Aerodox modular is that all I needed to do was add a boost converter on a new motherboard (daughterboard?) PCB. The results were great, at low cost. I had to remove the space I had left for a second button but since I don't use the buttons for anything, it wasn't a hardship. 

This log is well overdue but I honestly hadn't made any progress until yesterday. All the parts were here but the firmware was putting me off starting the hardware.

Hardware 

Apart from the opportunity for a pun, I thought I would see how long the diodes and hot-swappable switch holders would take to solder (a) with solder paste dispensed by hand and then the board reflowed and (b) soldering by hand. The solder paste, place and reflow method took me 25 minutes and the hand soldering of exactly the same components on the other half of the keyboard took me 35 minutes. That might not be interesting to you but I have often wondered where the threshold of hand soldering even SMT parts is compared to splodging some solder paste down from a syringe and plopping the parts on top. For clarity, I should say that the 25 minutes didn't include the 10 mins to reflow but I don't count that as I was able to use that time for other things.

Another interesting point about the reflow oven was that the PCB came out slightly warped, which may have been because I went too hot, too long or it may just happen with larger boards and large holes arrayed across them. So hand soldering may hold some advantages in this case.

I'm really pleased with the Kailh hot-swap switch mounts. Although this kind of design will suffer from rigidity issues without a (reinforcing?) plate around the body of the key switches, the ability to remove a key switch so I can solder in the vicinity has been great and I will be able to more cheaply move to new switches or a new PCB if I want to.

I'm also really pleased with my double-sided, SMD/through-hole enabled key switch footprints. This dramatically reduced the requirements for laying out traces or parts in kicad. Although I think that a python-based automatic layout script for custom key spacings wouldn't be too hard to do and might make future iterations very fast to generate.

The motherboard idea works well in a "bring up" sense. Although it's not as aesthetically pleasing, perhaps, it was essential for programming and troubleshooting and reprogramming and troubleshooting again (!) that I could easily remove the module from the keyboard. It basically allowed me to prototype on hardware that's good enough for final use.

Initially the motherboard wouldn't power up when I switched from the ST-Link power to the batteries. I suspected it was either (a) the 2*AA battery voltage was insufficient or (b) there was an issue with the way I had wired up the reverse voltage protection MOSFET. eBay (in lieu of a datasheet) told me that the voltage wasn't an issue and when I shorted the source and drain pins on the mosfet, the problem didn't disappear... See "Notes to self" below for the culprit.

The battery holders have a locating stub moulded into their plastic housing, which needs slicing off for a flush fit - there's no hole in my footprint.

Fortunately, a single M3 standoff is all that seems to be needed for tenting stability for now, until I make a proper frame.

Software 

The NRF51 motherboard was set up on Ubuntu with the instructions given at the very helpful #Redox keyboard Github repo. I haven't used this toolchain before so I really appreciate all that @Mattia Dal Ben has done for us there. The original Aerodox idea was to use an MCU and radio module pairing but the NRF51 is a much better arrangement at this stage and this first version of Aerodox is completely based on #Redox keyboard 's wireless version.

I had to spend a lot more time understanding the code for the NRF51s and qmk to have a clue how to get the key presses I want onto the screen. This is partly because I based my matrix on the ergodox and the redox has a rather different layout, which I'll come on to.

The key mapping has begun and I believe I can get all the keys to register now (I had issues with the additional row that Aerodox has over Redox and the column to key mapping). I haven't mapped them all properly because I need to rewrite the key map from Redox to suit Aerodox (with more keys and a different kind of thumb cluster.

There are some significant double types, which might be to do with the debounce in the keyboard side of things. I shall have a play with that. The response of the screen can also be a bit laggy but I could get used to it.

Notes to self 

There are several items which I'm just going to list here that I need to address in any publicly released version of the design. If you want more details, say so in the comments:

• Copper pours are not connected between battery protection MOSFET and motherboard ground. A solder bridge fixes this on the current version.
• Battery holder clashes with battery protection MOSFET on the left side - rearrange.
• The Redox column/row matrix wiring goes in the opposite direction to the Ergodox (which I used as my original hardware reference) - this means that the diodes need to be installed the other way round (don't ask me or my hot air gun how we know) and the silkscreen for the diode needs to be swapped direction in the next revision.

Outstanding 

I have yet to implement the switching between computers. I want to get the keyboard working nicely with one computer first and will then attempt the KVM (without V or M) switch mode later. 

This is leaning heavily on the fine work and assistance of @Mattia Dal Ben and his #Redox keyboard project. It uses the clone Core51822 module and has a couple of buttons and pullup resistors. That's it. I kept messing this board layout up so I wouldn't be surprised if it's connected up wrong when I eventually place an order for these. Here's the schematic. 

Note the pins are different from the #Redox keyboard because we have more rows, I also wanted buttons to change which receiver is being addressed and the header pins are just in a different order on the aerodox base PCB, so it will be better to change the configuration file than route traces across each other. 

There are also two pullup jumpers and I have extended the switch footprints to work on top or bottom sides, as this is a reversible board for both left and right halves of the keyboard.

Here's what it looks like. 

I have minimised silkscreen (only on the polarity indicator for the #SOICbite Programming/Debug Connector Footprint ) and used copper under soldermask where I can, for visual subtlety when installed. There are also standard 0.1" SWD pins, as I haven't tried using SWD with the SOICbite yet and I want a fallback if it doesn't play nicely with the programmer.

The unusual angles on the bottom right board edge are to allow clearance with the thumb cluster keys, which are quite close to the motherboard header pins. 

Oh yes, I also removed unused pads for the Core51822 module, to help escape the nets.

So @s0 has been reviewing the board files from Rev 0.2, where we moved to a demountable motherboard scheme. She asked about the P channel MOSFET that's used as a reverse polarity protection element and it made me realise that the P channel MOSFET will do nothing to help if we have VBAT connected to the spare pin on our motherboard headers. This got me thinking about how to protect all of the motherboard power pins. I wondered about a low side version of the same circuit, using an N channel MOSFET. Why don't we see that arrangement in articles/app notes about reverse polarity protection?

I think the answer given in a Stack Overflow/Exchange post is the most plausible - it's better practice to connect the low side of a load to GND, rather than something slightly above GND potential on the high side of an N channel MOSFET, so that different loads can share common GND. 

But in our application, having GND as the high side of the N channel MOSFET is fine, and we have a separate net for BATT- at a potential slightly below that. Now, if we want to connect USB or TRRS cables to a wired version of Aerodox, it doesn't matter that the battery's negative terminal is slightly lower potential than GND. There is nothing other than the MOSFET which needs to reference BATT-, so I think we're fine in this instance. 

One additional benefit of moving the battery reverse polarity protection from the high to the low side is that we can add a battery charging circuit and easily read battery voltage (taking in to account the small - perhaps negligible - voltage drop across the MOSFET).

Here's a summary of the changes. First, old Rev 0.2 schematic:

And now, new Rev 0.2a schematic:

and the resulting changes to the PCB

Anyone see any dramas with this?

The Outemu key switches, kepcaps, Keilh PCB hot swap connectors have all arrived, so I need to get on and design a first motherboard or two and get these PCB's ordered soon.

Since I started #Aerodox I have found more and more excellent other wireless keyboard designs. They use a range of controller and radio solutions (often combined in a Nordic chip). This made me realise that I probably want to separate the keyboard layout and matrix routing from the controller and radio. So I stripped back the PCB to just have batteries, reverse polarity protection, switch and key switches.

I broke power and the matrix busses out to two 8x1 0.1" headers, spaced far enough apart to fit most radio modules in, at 0.9", and still let the motherboard be placed in a breadboard with room to add wires outside the motherboard legs. "Motherboard" is what I'm calling whatever you plug into the aerodox pin headers. All the row and column pins, plus VCC and GND are accounted for. You wouldn't even need to make this wireless if you made your motherboard wired.

Perhaps I should change the project name to Omnidox.

Here is the new PCB

The motherboard will / can be plugged in any way up you like, so I have tried to make the header labels fairly subtle, using copper under silkscreen:

This will let me design a few motherboards. One will be based on the wireless version of #Redox keyboard that employs an NRF 51822, one will hopefully be based on this https://github.com/joric/qmk/wiki/jorne_ble that employs an NRF52840 but looks harder to port to my "KVM" requirement.

I'm still pondering the position of the thumb cluster though. Wouldn't it be nice if that were a movable feast?

After @s0 commented on some really good points, I'll just put this drawing up to show how I imagined the motherboard working. The 0.9" spacing is partly to give myself lots of margin in motherboard layout and routing to the two rows of pins. And then last night I watched Brian Lough's ESP32 BLE macro keypad video and realised that at 18mm wide for an ESP32 WROOM module, that would fit inside the rows on the motherboard, opening up a whole new area for control (ESP-NOW, anyone?), price, availability and hackability. I recall that ESP32 doesn't have a great performance on low power when its radios are in use, so this may be a dead end for a wireless version. Has anyone put QMK on ESP-32? I'm writing-before-googling so I bet it has been done.

I was thinking that the USB or TRRS connectors could be mounted to the side of the left row of pins for a wired connection. I don't think this would put too much mechanical stress on the motherboard pins. VBAT is a GREAT idea and we have duplicate GND pins because of an originally uneven number of matrix pins. So we can just lose a GND pin and have a VBAT pin. I will remove ground pours in the vicinity of the likely antenna position and shove the VCC trace over to the right. We can probably move the pins over to the right by a millimeter or two, and maybe up by the same.

Because I will be ordering some PCBs for work soon, I wanted to get this design finished in time to be lumped in with that batch.  It struck me during layout that there's no way I should be leaping in with the time investment of the PCB layout and the expense of PCBs, which let's face it aren't in the cheap size bracket. What I really should do is make a small macro keyboard, test that I can get that working and then scale up to a proper keyboard afterwards. But then I thought if I do that, I won't find out all the physical issues with my keyboard until the second revision. So that got quickly forgotten and layout continued.

I have added the schematic to the files for interest. I'll do a separate log on that. It's backwards but I'm sure you can work out how to read logs in reverse sequence. 

Big decision

The main keyboard layout decision I made was to stick with the standard ErgoDox thumb cluster position and layout. I reasoned that if I deviate from this on my first attempt, I'll never know which direction to go if I don't like it. If I don't like the standard one, at least I'll be able to reference my experience to the multiple reviews of people who have also tried this layout. Rev 0.2 could consider making the thumb cluster electrically separate, to facilitate changing its position.

Matrix wiring

You may remember that I spent some time working on a reversible key switch footprint in kicad 5.1.2, using the custom footprints feature. In case it's not obvious, these split keyboards save you money on PCB fabrication if you make them reversible (flip it over and populate it to create the opposite half of your keyboard). One of the reasons I tried to use the custom footprint feature, rather than just putting multiple pads with the same number on the footprint, was that I hoped to save having to manually connect those pins together using traces on the main layout in pcbnew (if I wanted to be able to use the DRC and not get flooded with false "unconnected" errors). For some reason that I'm sure is very helpful and prevents people making big mistakes, if a copper section connects two pads with the same number on the same layer, kicad doesn't consider those pins connected and will place an airwire in the ratsnest to point this out to you. As far as I can tell, the custom pad feature doesn't fix this either. Sigh.

Nevertheless, making a more reversible footprint was worth it to me in the end - routing the key switches was the easiest part of this design. And if they work/fit, I'll be able to share the footprint to hopefully save other people some time too.

Note that I haven't populated the 3D file for a diode or the "hot swap" switch holders here, so you can still see the pads. Those "though hole" pads are not plated and there's a gap between the drill hole and the copper annulus. This is one of the things which allows this to be wired up both ways round. Hopefully.

Close up on the front

The special jumper is there to join the two reset pins for the two ATtinys to one reset button when programming is complete. You don't want to do this beforehand because the reset pin on an ATtiny 1 series chip is also its programming and debugging interface, courtesy of UPDI. So two UPDI pins connected to one programmer would no doubt get confusing! I did consider another jumper as I understand QMK firmware can use pin state to determine whether a chip represents the left or the right hand half of the keyboard. But we can use the GPIOs for this if we want to go down that route (the chance of QMK running on these ATtinys is next to zero - it's going to be running on the receiver end).

The mode select buttons are yet to be defined but they seemed like the best way for me to switch quickly between different computers. Increment on one button, decrement on the other, perhaps with LED flashes to enumerate. I must say I do like the ALPS SPKM buttons. I first saw them used as slient options on homemade Arduboys (presumably to allow gaming in bed with a partner?) and added them to my own WIP arduboy compatible game console. They have plenty of travel for a tactile switch but I'm a kbd noob, so I don't really know how to describe them to you (yet). But they're small enough not to get in the way:

During the (inevitable) second board revision, there's every chance I'll think about swapping these for some right angle edge buttons like the reset switch. An edge mount button would be tidier, perhaps. But harder to integrate with cases that will more than likely come up the sides of the PCB.

I forgot to label it but just below the reset button is a P channel MOSFET and resistor as reverse polarity protection. 

Batterys as tent supports?

The 2x AA batteries are mounted on the rear but I have selected a holder that doesn't have a spring as the negative contact, so putting the batteries in the wrong way round is a risk that I need to design out.

The 3D file (and footprint) is just scaled up from the AAA holders that ship with kicad 3D libraries. I didn't have a proper look for 3D CAD for the Keystone 1028 (or equivalent) that I plan to use, which definitely doesn't have the spring contact you see here.

The batteries are on the rear at the back because I think I'll likely want a slight tent on this keyboard (tent is what people call the angle they prop their keyboard up at?) and will have Z to burn at the back. I was hoping to install the battery holder contacts between the first (furthest away?) and second row of keys but sadly the column staggering didn't allow this. You see, I wanted to keep the battery holders in-line, so I have the option that the batteries form part of the support at the rear, so I didn't want to fiddle with their alignment. Maybe on Rev 0.2.

Talking of the support. I have laced the PCB with M3 holes, with somewhat round-number spacing and an intent to use 3D prints, standoffs and machine screws to work out what the best pose for these is.

Firmware optimism

Finally, I had a squiz at QMK to see if there was any way to harness it with this wireless link in the way. I think there may well be. The support for split keyboards looks like the key to me - the adaptation of #USE_I2C for GPIO expanders allows us to send a matrix of key states/changes to the main microcontroller. If I get an ATtiny receiving messages on the NRF24L01 and acting as an I2C slave, I think this could work with "almost" stock QMK.

Just some snapshots really. I've been hunting down 3D files for key switches and keycaps, as I think on a project like this the kicad 3D viewer could be really helpful for identifying clashes.

First of all, I measured the dimensions of the key layout on the original ErgoDox. The 19.05mm grid was in use there, so the main dimensions I needed to be careful of were the thumb cluster (at  25 degree rotation) and the staggering between the individual columns. I then sketched a 4.6mm dia. circle in FreeCAD Sketcher: 

And exported to DXF. I had been hopeful that sketch points would appear on a DXF but I had to draw lines of some description to get it to export. Nevermind - the circles came in useful for lining up the key switch footprints over the correct position. That's why I needed at least 4.6mm circle diameter - to be able to see the footprint central locating hole concentricity with the drawing. I imported the DXF to the pcbnew drawing layer and started laying the switches out.

Two things were helpful here. In FreeCAD, I had rounded all dimensions (including the 19.05mm grid) to the nearest 0.1mm. Although I run a teeny risk of mechanical clashes (max error is 0.05mm, so unlikely) it means I can put the 0.1mm grid on kicad and be guaranteed to line my switch up with the guide circle. Obviously works with any reasonably fine grid spacing. The second thing in kicad was to start with the thumb cluster and use the Ctrl+m command to do a specified move. In this case, it was the 25 degree rotation for the thumb cluster switches. It's nicer than entering edit mode on each switch (press e) because it remembers the last transformation you did and keeps it in the relevant field(s). So you just press Ctrl+m and then Enter to accept.

Placing the switches goes quite quickly thanks to the alignment circles. 

One nice thing about a grid-based part layout is that it makes it easier to check you have placed the parts in the correct places:

Anyway, I'll leave it here for this session. We can see the form appearing:

I'm only a couple of days into initiation in the world of keyboards. At first you grab a design you want to either copy or develop your own from. But then you read further and you find all the people who don't like that design. Of course, human machine interfaces are going to be about as standard as humans, so some disagreement on the optimal physical layout is to be expected.

Because I am spinning my own PCB for this keyboard, I get to move the layout away from the standard ErgoDox. My suspicions were aroused that I might want to seriously look into this when @kristina panos mentioned that she found the space bar easy to miss on her standard ErgoDox PCB. Some of that is down to muscle memory from her previous keyboard, no doubt, but it did seem strange that one of the most used keys should be so illogically placed for a seasoned keyboard user. She's not the only one.

Lo and behold, there exists a wide variety of opinion in ErgoDox-related threads specifically on the location of the "thumb cluster" of keys that the spacebar resides in. So, I decided to take the existing layout, print it at 1:1 scale and see where my fingers and thumb naturally fall.

With my fingers on the home keys, it does seem like the cluster is quite far over to the left and I had to strain the thumb to get it all the way over to the three 1Us on the left. I realise this isn't very realistic and that many hours of testing and optimising have probably gone into the ErgoDox physical layout, so it would be quite a leap for a first-time mechanical keyboard user, let alone designer, to depart from the original. Here's what I'm thinking of.

The red key outlines are the original ErgoDox key locations; they're not all populated in the diagram, obviously. Blue outlines are the home keys (as far as I can tell). The light blue, semi-transparent arc is where I think my thumb naturally sweeps when fingers are on the home keys (referenced to the middle of my distal phalange). The green outline keys are where I'm considering moving my thumb cluster to. The fine orange line is an indicative new board edge.

Some people have said that the Keyboardio has a better thumb cluster layout, which does seem to map quite well to the  thumb sweep above, but perhaps doesn't provide large enough buttons.

Do any experienced keyboard users have any sage advice about the folly of an idea to move the thumb cluster like this?

I think I may have managed to make a key switch footprint for the Kailh hot swap PCB inserts/adapters. 

The reason I want to be able to hot swap my key switches is because I may not want to keep the first ones I try (probably box browns). Here's a footprint which I think is reversible and will save time during layout.

The only downside I can see at this stage is that the diode symbol could be confusing. Bear in mind that if we're looking down on the PCB, the hot swap insert is connected to the bottom layer (green) and the diode direction we want is in the bottom silkscreen (magenta). I did this because the surface mount diodes are likely to get reflowed on the same side as the hot swap inserts. Obviously, if you are placing a through hole diode, you are less constrained by the reflow, so you may choose to hand solder it on the other side of the PCB, in which case you still need to heed the diode direction on the bottom layer, not the top layer. The rule is "correct diode direction is on the same side as your hot swap insert pads".

Here's the 3D view of the front 

And here's the back

There are only two "user" pins in this footprint - top left rectangle pad and bottom left "D" pad. Note that none of the pads down the bottom are PTH. They are copper annuli and non-plated holes, which adds another layer of complexity for the through-hole-diode constructor but achieves the symmetry required to allow the PCB to work on both sides. It was painful and I needed to use custom pad shapes in the footprint editor, as well as putting the soldermask and paste layer apertures separate to the main pads.

I thought I was done and then I realised that the mirrored pads that weren't being used would be expecting joins in the ratsnest, so I added more traces and makeshift vias (PTH with same pin number and without soldermask). This one is trying to not get in the way of the LEDs that are in some footprints. 

Finished footprint (for now)

I'll see how it goes when I try and lay the board out. Schematic next.