Almost a full year later, in March 2023, Doug emailed me a third time with another commission request. Although I had built the two previous keyboards precisely to his specification, he still felt the final result was not an ideal replacement for his Merc Stealth, so he had a radically different proposal. He wanted to send me one of his Merc Stealth keyboards so that I could convert the internals to become a mechanical keyboard. This approach--if viable--would virtually ensure that it had the same layout and feel as the original Merc Stealth.
At this point, I realized a few things:
To determine feasibility, I would need to examine a Merc Stealth up close, so I accepted his offer to ship one to me for evaluation, after which I could determine whether I could do the job. And even if I could do it, whether I would actually want to take it on.
While I fully anticipate that some readers will have no appreciation for this particular layout, it turns out that there are quite a few people who have used this gaming pad layout for upwards of ten to fifteen years, and they now refuse to use anything else. Their muscle memory is too well-formed, and the convenience of the full number row within reach is far too great.
From a purely technical standpoint, the Merc Stealth was somewhat underwhelming and problematic. Aside from being a membrane keyboard that wears out after a few years of heavy use, there are now driver compatibility issues with modern operating systems, and the keyboard itself only supports 4KRO (that is, four key rollover, so only up to four keypresses are detected at once).
Some people online speculate that the Merc Stealth layout couldn't be reproduced by others because it was patented; I searched the USPTO website and found no patents from either Ideazon or SteelSeries to substantiate this claim. This finding is consistent with my understanding that keyboard layouts are inherently not patentable (but I am not a patent attorney, so if I missed something and there actually is a relevant patent, please send the relevant patent number to sales@custommk.com).
Within a few days, Doug's Merc Stealth arrived, and I began to take it apart while taking measurements in earnest. First, I discovered that MX switch stems could fit (albeit loosely) inside the original keycap stems when rotated at a specific orientation. So it seemed that I could reuse the original keycaps, but I would need to glue or epoxy the keycaps onto switches.
Because of the nonstandard key sizes and placement, there was no normal "1u" grid layout to follow. Locating each switch precisely--and at the correct orientation to fit in the keycap--would be a challenge. To overcome this problem, I generated a 1mm x 1mm grid and printed it on paper. I then laid the original Merc Stealth membrane on top of it, fixed it in place with pins, and poked pinholes through the membrane and grid paper at each of the switch centers. This gave me measurable coordinates for all the switch centers, which I could then plot and visualize to confirm the measurements. This also allowed me to 3D print a "faux PCB" to perform fit checks.
However, these fit checks revealed yet another problem: not only are the keycaps smaller than typical 1u keycaps, they are so small that I couldn't even fit MX switches underneath them. That is, even reusing the original keycaps, the MX switch housings would physically interfere with each other. This was a massive problem, because if you can't fix MX-style mechcanical switches, you can't really have a mechanical keyboard at all.
As it turns out, there are many parts of a mechanical switch, and not all of them are important in every keyboard. Overall, the housing and clips hold the switch together (required), the stem attaches to the keycap (required), and the metal parts make electrical contact (required). But around the very edge of the housing are bits of plastic that help it clip into a switch plate. If you go with a plateless keyboard design, those bits of plastic are unnecessary. Likewise, there is a portion of the switch reserved for LEDs or light pipes for backlit keyboards. Since I wasn't planning to give ErgoStrafer per-key backlighting, this portion of the switch housing could also be removed.
Those two observations alone resulted in enough removable material that I could actually use a Dremel to cut down switches to fit in the tight space demanded by the layout.
After using the 3D printed faux PCB to confirm that the cut-and-rotated switches would fit, I started testing the keycap installation process, and once more, a new problem was discovered. When attaching keycaps to the switch stems, the adhesives required time to set, which meant holding them in the precisely correct position for a lengthy amount of time. Meanwhile, the adhesive also flowed into other parts of the switch, gumming them up and interfering with switch operation. After the adhesive had set, the outer diameter of the keycap stem ended up being too big for the switch to reliably actuate (the keycap stem could hit the top of the switch housing when pressed). Lastly, without good surface-to-surface contact area within the stem, the adhesion overall was poor, and the keycap would easily break off from the switch.
This was (again) a significant setback because neither of the backup options were ideal. For the first option, I could cut the stems from the original keycaps, and then cut off most of the keycap surface from normal MX keycaps. This would allow me to glue the Merc Stealth keycap surface onto an MX keycap stem, but that requires a lot of manual labor per keycap and introduces ample opportunities for alignment errors (the keycaps might not be centered or rotated correctly).
The other option--3D modeling and 3D printing each keycap--would take a lot of tedious work to do right. The keycaps are all sorts of odd shapes, with concave and convex surfaces, bevels, slants, and differing key heights. 3D printing the keycaps would also mean that ErgoStrafer would not have legends on the keycaps. But...3D printed keycaps would at least be consistently reproducible and require less hands-on labor. If I wanted to make additional ErgoStrafers, it would sidestep the need to scavenge original keycaps (which will likely be increasingly hard to find).
Ultimately, I chose to 3D model and 3D print the keycaps. That process is documented in a separate article which you can find here.
Armed with 3D models of each keycap, I was able to more fully flesh out the entire assembly in FreeCAD by incorporating switch models and keycaps. At this point, because I had well-defined shapes and placement for each keycap, it seemed increasingly more reasonable to move away entirely from the concept of re-using the original Merc Stealth case and instead 3D print a dedicated case. So I decided to do that....and immediately stumbled into a few new problems to solve:
It was around this time I also had a few realizations and insights about the overall layout which helped to finalize all keycap and switch dimensions and rotations with greater certainty and precision. I discuss those topics in more detail in this article posted to the customMK Patreon. One nice side effect of that improvement was that it allowed me to effectively reset all the switch orientations to be consistent (aside from the top right keys which are rotated 10 degrees relative to the others) which helped to make the switch cutting process less random.
Diagram showing required switch cuts for ErgoStrafer
In January 2023, I published an article about our Engikeeb experiments, which caught the attention of the folks at PCBWay. They graciously offered to sponsor our next project, and ErgoStrafer seemed like a good fit. So I took them up on their offer--not just for the PCB assembly, but also for all the 3D printed parts as well! I want to give a huge thank you and shout out to them for provding direct support for these innovative projects. PCBWay was very easy to work with and the parts all came out very nice!
Aside from switching to mechanical switches and eliminating driver issues by using QMK, I found other opportunities to optionally make ErgoStrafer even better than the original Merc Stealth:
I decided to give EgroStrafer the same powerful hardware used in the open source Bonsai C4: a very fast ARM microcontroller running open source QMK firmware to scan for keypresses several thousand times per second. It also includes 8kB of FRAM for storing settings, which provides up to 32 layers of custom key assignments in VIA and plenty of room for custom macros. Also, the 4KRO limitation of Merc Stealth is replaced with NKRO, meaning that all the keys can be pressed and detected simultaneously.
ErgoStrafer VIA Screenshot
Because I hadn't personally owned and used a Merc Stealth, I was in no position to evaluate whether it actually met the goal of being able to replace it and fully satisfy Doug (and presumably anyone else using a Merc Stealth). After a few days of nervously waiting for the first ErgoStrafer shipment to get to Doug, I had my answer:
Doug was happy--I was happy.
With that feedback that it was a success, I added ErgoStrafer to the customMK product listings. While it is more expensive than I had hoped it would be (albeit nowhere near "$2k expensive"), it is because the parts are expensive and the touch labor is high. In particular, the case consumes a lot of 3D printer resin, and the assembly process requires manually cutting down switches by hand (or rather, a Dremel). To try to provide more affordable options, I've included both black and white 3D printed parts because for some reason the 3D printed white parts are lower cost.
I've also listed the most essential components--the PCB and keycaps--as items that can be purchased separately. This allows customers to avoid the expensive material cost of the case and eliminate my time and labor cutting down switches to fit and assembling the switches, keycap, and case.
]]>
Additionally, each type of key has a different height relative to other keys. Fortunately, the membrane internal to the Merc Stealth keyboard can be represented as a flat plane, so measuring the differing key heights was straightforward (by measuring the bottom of the keycap stem to the top of the keycap).
In total, there are 13 different keycap shapes used in the gamepad layout, but I added a 14th key (the Ctrl key from the main keyboard) at the request of Doug, who commissioned the design of ErgoStrafer.
To capture the shape of the prominently-featured butterfly keys, I took a photo of the original keyboard layout from directly above the keys at a relatively far distance (to minimize parallax distortion). In the photo, I also included the digital calipers to provide a reliable reference for real-world distances. I then imported the image into FreeCAD and scaled it until the measurements on the calipers matched the dimensions used within FreeCAD.
With known-good dimensions in the reference photo, I created a sketch parallel to the image plane and used the spline tools to trace the outlines of each keycap switch individually. Or rather, I traced approximately 1/4 of the outlines because the butterfly keys have a healthy amount of symmetry from left-to-right and top-to-bottom.
For example, with the "s" key, I only traced out the part of the switch contour, and for the rest, I added an equal number of spline control points. Using the sketcher symmetry constraints, I could force the other quadrants to mirror the first portion precisely and then make minor adjustments to ensure the best overall fit to the photo. Similarly, while the top-left "q" key does not have any internal symmetry, it is still a mirror image of the "e" (as well as the "z" key I added).
Once all the butterfly keys were defined in two dimensions, I extruded each of them to an excessively large height. To add the common concavity across all six keycaps, I measured the depth of concavity and added a sketch with an arc matching that curve, and then swept that arc through the keycaps using the Groove tool.
At that point, all the top surfaces of the keycaps were nearly complete, except for the addition of a the small homing bar on the "s" key.
With the keycap surfaces taking shape, I then needed to add the MX-compatible stems. Fortunately, there were other keycaps I could use as a reference, despite finding a few differences between them. Ultimately, the two best resources I found were these:
https://github.com/rana-sylvatica/circle-keycaps
https://github.com/toniz4/PseudoMakeMeKeyCapProfiles
Unlike downloading STL files from Thingiverse and trying to take measurements of features, the use of SCAD files in these projects for parametric modeling meant that I could open up the SCAD file in a text editor, read through the code, and precisely duplicate known-good MX stem dimensions.
3D printing services generally apply a minimum cost per part, so it can be helpful to organize parts together in a single design. This helps ensure that the costs are based on the total mass and print volume of the design, as opposed to incurring a minimum charge. However, the rules governing such groupings vary from supplier to supplier:
Overall, PCBWay made it very straightforward to print with whatever I had already 3D modeled, whereas JLCPCB felt like a puzzle to solve to avoid arbitrary rulebreaking and fees. Of course, this tends to mirror how the two companies handle PCBs as well: PCBWay will build whatever you send them, JLCPCB requires you to use parts from the JLCPCB Parts Library (or consignment). There are pros and cons to both approaches. For example, you can get a comprehensive, instant online assembly quote from JLCPCB (because they limit you to their parts library, so they already "know" every part you could use in a design), whereas PCBWay has a person in the loop to calculate component purchase and placement costs. They are just two different-yet-valid approaches depending on your particular needs.
While most of this article focuses on the design of the keycaps, there is an element of the keycaps that impacted the case design: the case had to include a hole for each keycap. To make those holes, I used the original 2D keycap sketches and simply added a second spline just outside of the perimeter of the original keycap. I made sure to include an identical number of spline control points as the switch I was surrounding, and then added a dimension constraint between each of the original keycap control points and the new spline control points. I fixed this dimension to about 1mm for all the control points, and around the edge, and manually ensured that the dimension lines are roughly perpendicular to the original keycap boundary. This new outer line then served as the case opening for the keycaps to protrude through.
After getting the keycaps 3D printed, there are a few things I learned that will impact how I make them going forward:
Overall the process went remarkably well. The few (entirely preventable) issues resulted from my own decision deviate from their recommendations, and I have incorporated changes as needed to avoid those issues.
Overall, the process of designing non-standard keycaps for ErgoStrafer and getting them produced went really well, despite the somewhat tedious design process. The resulting parts look good, fit right, and feel great.
]]>We used only free and/or open source tools, so Solidworks and Fusion 360 are unnecessary--but we did make use of 3D Builder which is freely included with Microsoft Windows. To save you time, here is a quick summary of our process:
I’ll also explain a bit about the filetypes involved because it is actually pretty relevant and a source of potential problems.
For "bigger picture" context: customMK accepted a keyboard design commission earlier this year to reproduce the SteelSeries Merc Zboard gamepad layout as accurately as possible using mechanical keyboard switches:
We ended up creating (or re-creating?) 3D models for the keycaps and case, and we are having it all 3D printed. This is still a work in progress, as parts are currently being 3D printed. While it is not released yet, we have decided to call the product “ErgoStrafer" and we have an Interest Check for it here.
For this design, the keycaps are not standard MX keycaps, so creating 3D models of the keycaps from scratch was a necessary step in the process. We considered simply re-using the original keycaps, but they were not designed to fit the stems of MX switches (just FYI, the original keyboard was a membrane keyboard, not mechanical). We will be covering much more of the design process for this particular keyboard commission in future articles, but the focus of this article is specifically “how to add color to 3D models for 3D printing” (importantly, without buying expensive CAD software).
I should also mention that adding legends to the keycaps was *not* within the scope of the commissioned work. Our customer, Doug, is perfectly happy to receive blank keycaps because he already has over a decade of muscle memory trained on this layout. The reason we wanted to try to adding a legend is because….well, it seemed like a fun and interesting thing to do. If the result actually looks good, then this method can provide an alternative to producing full-color artisan keycaps without needing to hand painting them (so they are more consistent and less labor-intensive). However, full-color 3D printing is still rather expensive--comparable to artisan keycaps at "tens of dollars per keycap", so we’re only making one keycap for now to just flush out the kinks in the system and get to a proof of concept.
JLCPCB and File Formats for 3D Printing
JLCPCB offers a variety of 3D printing capabilities, one of them being full-color 3D prints. There are only a handful of 3D printer technologies capable of achieving this, but based on the material choices available it seems that JLCPCB may be using HP's color 3D printer technology, which was sadly discontinued last year.
To upload a 3D printable file for multicolor prints, there are a few additional requirements above and beyond normal 3D printing. Specifically, in addition to there being a watertight mesh of triangles (e.g. STL files for the past decade) to form the outside surface of the item, there must now be colors assigned to the surface as well. Traditional STL files fall short of this capability, because they do not contain color information. It is worth noting that colors are assigned to the surface mesh only, so color will only be applied to the outer surface of the 3D print.
JLCPCB requires that the uploads must be either 3MF format or OBJ format for full color 3D printing. 3MF is a relatively newer open standard that is intended to an "all-in-one" file for all kinds of 3D printing. The file format requires that the contents be a closed manifold (i.e. watertight), and it can also contain color and texture/image information within the 3MF file itself.
The OBJ file format has been around a little longer than 3MF, but interestingly OBJ doesn't actually store color or texture information internally. If you have colors assigned to faces or mesh triangles in your 3D modeling tool, then exporting to an OBJ file will not only create the OBJ file, but also create a MTL file (material file) as well, which contains surface color information. Also, if surface textures (i.e. images) are used, then a JPG file (or other image files) are created as well when the OBJ export happens. Thus, the OBJ file refers to an MTL file which can refer to a JPG (or multiple JPGs). You can see this process happen in reverse with some modeling software when importing an OBJ file—for example, upon importing an OBJ file with color, Microsoft's 3D Builder asks you to locate the MTL file (even if it's already in the same folder as the OBJ), and--if needed--will also ask you to locate the JPG file(s) as well.
Generating a 3D Mesh With Edges at Color Boundaries in FreeCAD
So with that context, when you try to search out information on how to add color to 3D models for 3D printing, the most common search results start with "Solidworks makes this very easy, all you have to do is..." but…..Solidworks is not free software, and I don't own it, so those search results are somewhat less than helpful. Fortunately, with a handful of free tools, you can still get the job done.
My starting point was FreeCAD, because that is my preferred CAD tool for parametric design. I won’t cover the overall keycap shape modeling in this article, so the starting point is “I have a keycap 3D model.” Once you have a 3D model in FreeCAD, you *could* export to an OBJ file immediately, but in my case, I also wanted to use FreeCAD to rearrange the surface mesh to provide the outline for the legend. That is, for the keycap I had precise placement of lettering/shapes that I wanted, which made sense to do in FreeCAD. We took the keycap 3D model and create two solid bodies--one for each desired surface color.
At this point, I had two solid objects: one was the original object with some material removed, the other was a shape to fill in the removed material. I used the Parts Workbench to union these together get back to the original shape, but now with the added distinction that the 3D mesh edges were guaranteed to exist at the boundary of the keycap legend:
To drive home the relevance of that distinction, let's convert both the original keycap (without legend) and this updated keycap (with legend) to a 3D mesh using FreeCAD's Mesh Design workbench:
You can see the original keycap mesh on the left is pretty straightforward, no surprises. But the keycap on the right that we took through the legend process now has a bunch of additional triangles dedicated to the legend shapes. The "S" in particular is readily observable here.
Adding Solid Colors and Image Wraps to the 3D Mesh in Blender
To make the mesh even more visible, we can export using Meshes -> Export Mesh, and save it as a 3MF or OBJ file. We can then open up Blender and import that file, which looks like this in Edit Mode:
Note that if you want to import/export the 3MF format with Blender, you will need to install the 3MF addon. In my experience, the 3MF format kept the size consistent, whereas the OBJ approach resulted in units being changed (mm to m), so a 1:1000 scaling transformation was required to correct it.
With the mesh now in Blender, we can do all sorts of fun Blender-y things like UV wrapping and assigning materials to each triangle of the mesh independently. Here is an example tutorial video showing how to add an image as a UV wrap to an object. Here is the process I used to apply color to the mesh:
Preparing Files for Upload to JLCPCB using 3D Builder (and a zip/compression tool)
At this point, most of the hard work is done! The keycap is a complete mesh with the correct textures applied. Unfortunately, there seems to be some problem with the 3MF import/export addon for Blender, at least for me. So instead I exported to OBJ (which created an MTL and JPG file as well). As of May 2023, for color 3D prints, JLCPCB only lets you upload 3MF or OBJ files. They do not let you upload any MTL or JPG files, nor any zip file containing OBJ+MTL+JPG files. If we upload only OBJ files, there will be no colors or textures applied, which defeats the purpose of a full color 3D print. So 3MF is currently the only viable format for uploading full color 3D models to JLCPCB.
Also, fun fact: having a multicolor 3D printed keycap costs more than twice the cost of a full metal 3D printed keycap! Anything involving color printer ink always seems to have that sort of effect...while the cost to print is entirely unreasonable for normal keycaps, it at least appears to be somewhat in line with artisan keycap prices.
With the OBJ file exported, I then used Microsoft's 3D Builder to importe the OBJ (and related files) and then re-exported it to the 3MF format (because JLCPCB accepts the 3MF file format for multicolor 3D print uploading). I checked with several tools to ensure the file was good and complete. One of them was the HP SmartStream 3D Build Manager--because if that software can't open it, then an HP 3D printer is likely going to have problems as well. I also found https://3dviewer.net/ was useful for doing quick reality checks of the 3D models.
There was just one more step to do which is going to seem enitrely unnecessary, but…whenever I uploaded my 3MF file to JLCPCB, the upload server immediately rejected it with some vague server error. Talking with JLCPCB support and sending the file via email, they said were able to "fix" my file so that it would upload, but I still wanted to get to the root of the problem (so that I wouldn't always have to get JLCPCB to fix my files). After a lot of experimentation, it appears the 3MF file output from 3D Builder has some inherent incompatibility with JLCPCB's upload process (at least as of May 2023). Under the hood, the 3MF file format is just a zip file that stores an XML file containing the mesh data, JPG or PNGs for textures, etc. To get the file to actually upload properly to JLCPCB, I had to take the original 3MF file, rename the extension to .zip, Extract All to a folder, then go into that folder and compress the contents back to a zip file, and finally rename the zip file back to a 3MF. For some reason, simply extracting and re-zipping the 3MF contents fixes the issue. Why that is....I don't know...but it works!
At this point, the all 3D models have been sent off for manufacture, some parts have started printing (as shown in an earlier photo), and we are eagerly waiting to receive them. Stay tuned to see how the full-color 3D print turns out (we’re excited to see how it goes as well!) and to learn more about the design process we used to create ErgoStrafer. In the meantime, feel free to check out our EVO70 R2 keyboard kit (limited quantities remaining), subscribe to our Patreon for more in-depth behind-the-scenes content, or join our Discord server to just hang out and talk about keyboards!
]]>
While thinking of ways to make mechanical keyboards more affordable, I had an idea for a "Single Board Keyboard" (SBKB): a single PCB intended to be the entirety of the keyboard. No case required. No switch plate required. Minimal soldering required. Such a PCB would have:
The slide switch could perform two different roles: for wireless use with a nice!nano it serves as a power cutoff switch, and for wired microcontrollers it can operate as a configuration switch that does whatever you want, such as switching between MacOS/Windows mode or disable/enable the status LEDs.
The target cost for the PCB seemed like it should be around $10 or less.
After letting the idea simmer for a few months while working towards the EVO70 R2 group buy (which ends January 31), I decided to try making a prototype SBKB. Part of me just wanted to test the concept to see if it was actually viable, and the other part simply wanted a dirt-cheap full size QMK mechanical keyboard to use for myself (because I was still using a full-size membrane keyboard). Making an SBKB would also give me the motivation and excuse to learn how to make use of ZMK for wireless as well. By supporting a variety of layout options, I could also cheaply experiment with both a traditional layout and interesting options like split backspace, split spacebar, WKL, HHKB, etc.
Here is the schematic for Enigkeeb (with minor corrections applied):
If you read no further, here's a quick summary of the results:
After testing it out, there were only two significant concerns with the SBKB concept, neither of which were showstoppers. First, the board can flex a lot--so much so that it can interfere with spacebar stabilizer operation when not resting flat on a desk. Second, the board really needs to be tape-modded (I used butyl tape) to protect the exposed electrical connections on the bottom side of the board. Acrylic covers over the microcontroller on top is also highly recommended as well.
Engikeeb is a full size, ultra-low cost, highly configurable keyboard, with a unwavering focus on functionality. I liked that it wouldn't hurt my wallet much to buy multiples of them, and I could quickly and easily populate them with cheap switches and stabs in a variety of configurations. If I found that I didn't care for a particular layout after trying it, it wouldn't be a big loss to discard it or donate it to a friend. The best part: because diodes are pre-installed on the PCB, I wouldn't even need to hand-solder in the diodes. Because Engikeeb is low cost, it helps enable multiple iterations while exploring different layouts.
After settling in on a favorite layout, I could then build one up with nicer switches, install an encoder, and select from a variety of displays. Engikeeb can support several typical displays:
Here are all the supported layouts of Engikeeb (noting that the southpaw version is identical, except the numpad/encoder/displays/USB connection are on the left side).
For my prototype build, I decided to socket the microcontroller and displays, because I planned to swap them out frequently during development.
Here is the resulting PCB (this is the southpaw version):
And here is a closeup of the microcontroller and display section:
The center of each switch location is conveniently labeled with silkscreen indicating the size(s) of the keys meant to be installed in each switch location. This came in very handy for the bottom row as it helps find the right placement for each switch, despite supporting a wide variety of layouts.
Upon building up the keyboard, I discovered a few small errors in the design which is not uncommon for first-time-builds:
Design defects like this aren't fun to discover when you've made 60 prototype boards, but it helps to realize that I only made a lot of them because they were incredibly inexpensive.
At quantities of 30 each, the blank PCB cost around $5 each, the parts (with assembly) were around $2 per PCB, and the shipping worked out to be around $3 each. However, that doesn't tell the whole story. If I only made two PCBs of each, I would have spent closer to $75 per PCB because JLCPCB charges setup costs per job, and shipping charges are high even if you only make a handful of boards. So my options at the time of checkout were:
With an incremental cost per board around $5, it was well worth it to get quite a few more--just in case everything worked right the first time.
One of the more interesting features of Engikeeb is that the board accepts the wireless nice!nano just as easily as the wired ProMicro and Bonsai C4, and uses a slide switch for both battery disconnect (in wireless mode) and as a settings switch (in wired mode). To achieve this, the board needed a special circuit to handle the battery. Here is that circuit:
In the top right are the battery connections; I allowed for both soldering to thru hole pins (for batteries with pigtails) and for a battery with a standard JST connector.
In the top right is the connection to the bat+ pin of the nice!nano. For ProMicro and Bonsai C4, this happens to be the +5V raw pin.
In the bottom right is a MOSFET that (for all intents and purposes) performs just like a mechanical switch.
When using a battery with nice!nano, the switch physically disconnects the battery from the microcontroller power pin, and harmlessly redirects the battery voltage to the gate of a MOSFET. In the other switch setting, the battery directly connects the battery to the microcontroller as you would want it to do in normal operation.
There is a pull down resistor of 4.7k to ensure the MOSFET gate is in a known low state when the gate is not connected to anything else, but in the future this resistance will be increased a lot, likely to 10Mohm or so, because (1) it passively discharges the battery faster than it needs to at 4.7k and (2) the switch detection speed can be slowed down a lot because it is not used as a typical mechanical switch, and also the gate capacitance of the MOSFET is really low.
With this approach, the raw 5V (which is present when ProMicro or Bonsai C4 is used) or the battery voltage (which is present when nice!nano is used) never reaches the switch matrix pins of the microcontroller. Because there is a MOSFET Q1 between them, this circuit is able to perform the dual roles of a power switch for wireless and a "normal" configuration switch in wired modes.
In addition to putting surface mount diodes on the board, I also added shift registers for my own sanity. Basically, with the shift registers, I can have a massive number of either rows or columns, all controlled by just three microcontroller pins. Each shift register only costs a few cents, and the 74HC595 shift registers can be chained together and driven through SPI communications. Shift registers are actually becoming so common in keyboards that ZMK even has a built-in driver for them.
The best part of using shift registers is that it lets you use a normal-looking matrix. Normally, to fix 104 keys, you'd need at least 21 keys, and you would "square up" the matrix in a 10x11 grid to fit them all in. Then you're having to keep track of which matrix location corresponds to each physical location on the board, and then which keycodes map to those locations...it can be overwhelming to say the least.
With shift registers, I set up six rows using six pins, and 21 columns using three pins. This produced a nice rectangular matrix that matched my approximate layout, and even left me with three shift register pins to spare (since three shift registers * 8 pins each = 24)...which I conveniently used to drive the three status LEDs.
I'm somewhat on the fence about ZMK overall. ZMK is the wireless firmware that I ran on the nice!nano. I figured out how to use it, and sure enough, it works, but it's a very different beast from QMK. With QMK, I can write whatever code I need and the microcontroller will just do it. With ZMK, there isn't (so far) an opportunity to easily inject custom code. The optimal way to approach ZMK is to think of it as just selecting from available options for your keyboard. Each row/column pin is an option you specify, the keymaps are options, even the display is just something you can enable or disable--ZMK manages for you what is actually shown on the display and where things go. This is radically different from QMK; in QMK I was able to do crazy things like convert bongo cat to a font to compress the size for displaying on an OLED. But ZMK is still growing and they have more plans for development in the future. In all fairness, ZMK did work well for what I needed it to do, even if I felt locked out from the relative develoment freedom of QMK.
Two other small findings I made about Engikeeb:
I got the offset wrong by about 0.5u for some of my function keys. If I use the layout with F13, it's not a problem, but using the F12 layout, it's off by a little. Not a big issue, but just something I noticed.
QMK doesn't support multiple SPI buses (yet) so for Bonsai C4, I can't use both the FRAM chip of Bonasi C4 and an SPI-based LCD. This is because the FRAM chip and the LCD displays are on a different SPI buses. I suspect someday in the near future QMK will have better support for this (I've conversed with QMK devs about it, it's on the radar), but in the meantime, it just means I have to use the wear-leveling flash-as-EEPROM if I want to use the LCD displays. Again, no big deal, but just a nitpick.
I absolutely love my Engikeeb, but I'll be the first to admit it's not for everyone. The entire supporting structure is one sheet of FR4, so the flex is quite nice while typing, and with butyl tape all over the back and no case to speak of, the sound while typing is pure thock (particularly the ANSI enter key for some reason).
With the defects in the original design, I'm not inclined to sell the extra PCBs I have simply because of the time it will take me to fix them. And so while it is a good experiment in just how "low cost" I can make the board, in practice I can't actually sell them for so little because there are always other expenses involved (25% import duties for larger orders, boxes/packaging, the rubber feet, labor/handling to pack and ship them, online product support, and optionally some laser cut acrylic pieces to protect the microcontroller and butyl tape for the back side).
That said, if there is interest in SBKBs overall--even for other size keyboards--feel free to let me know on the customMK Discord or via email. If there is enough interest, who knows where things can go from here.
]]>While we have already shipped about half of the orders for EVO70, there are still many who have not yet received their kits. If you haven't been following the more frequent updates I provide on our Discord server, then you may be out of the loop and wondering when your kit will arrive. (the short answer is June) This post explains the reason for the delay, but feel free to contact us directly at sales@custommk.com if you have any further questions about your specific order.
Earlier this year, our assembly shop in China was scheduled to receive a shipment of aluminum pieces for EVO70. Unfortunately, that did not go exactly as planned: only some of the aluminum pieces were delivered (the rest still haven't arrived to this day) and of those pieces that were delivered, ALL of the e-white switch plates were badly warped. This level of warping was simply not acceptable to us:
In response to this alarming news, we contacted about a dozen other aluminum suppliers to request quotes to remake the missing and warped pieces. After a few weeks, we selected one aluminum supplier to remake the parts. The new supplier not only had prior keyboard manufacturing experience, but also could commit to delivering the parts in about one month, minimizing the overall schedule slip. customMK covered the cost of remaking the parts from even though the cost was quite a bit higher, because from a business standpoint, it was worthwhile to ensure high quality and a quick turnaround time.
Ultimately, the new supplier successfully made the parts in a timely manner. However, overall, the process resulted in a schedule slip of approximately two months for EVO70 deliveries. As of last night, we now have a tracking number from our assembly ship for most of the remaining kits, which are headed towards us now. Express shipping to us is expected to take about a week, and then we will fulfill the remaining EVO70 kits orders as quickly as we can over the next few weeks.
There also is one other issue that was encountered during assembly; namely, some of the acrylic mid pieces needed to be remade, which was discovered in the last week or two. The acrylic pieces are being re-made, and so these kits are about a week behind the others. They should be shipped to us starting next week, at which point all remaining EVO70s will either be in our possession or on their way to us.
The overall summary (as provided by our assembly shop) of what has already shipped from China and what will ship is shown below:
So to summarize:
When your order is fulfilled you will be sent a tracking number via email. We fulfill order in order number, provided that we can actually fulfill your order with what we have here (i.e. we can't fulfill what we don't have yet).
For those who have not received their kits, we thank you for your patience, and you will have your kit soon! If you would like to see how some of other kits we've already shipped have been turning out, feel free to join our Discord server where many people have been uploading photos of their EVO70 build.
As keyboard enthusiasts ourselves that have missed past group buy opportunities, we fully understand the frustration of missing a group buy. After the group buy ends and we start building your orders, we take a look at the percentages of what all was ordered, and then we scale those a numbers up a bit. That is, we invest as well, buying quantities above and beyond what everyone ordered in the group buy. We then make the additional quantity available for purchase after the group buy ends. These are available as pre-orders. So even if you miss the group buy, pre-orders can give you the opportunity to join in and receive your order at the same time as the rest of the group buy participants.
However, unlike buying during the group buy phase, pre-orders are very limited in quantity. Specifically, they are limited to however many additional kits we purchased, and in whatever colors/styles we purchased them in.
So if you missed out on the group buy--great news--you still have a chance to join in, but please be aware that your options may become more limited as time passes.
]]>As mentioned in our last update here, we had received the wrong rubber feet from our supplier, but the replacements have arrived so we can now start shipping!
Edit: firmware and VIA JSON last updated 3/16/2021
And as mentioned in another update here, we wanted to make it even easier to modify the encoder functionality so you can change it to operate like a mouse scroll wheel, function keys...you name it! So now we've generated new firmware and a VIA JSON file that lets you dynamically map the encoder rotations to whatever keypresses you want, without having to recompile. To upgrade your Genesis to do this, follow these steps:
And that's it! The two keys in the top left of the VIA layout will be virtually pressed whenever the top left encoder is rotated counterclockwise and clockwise and the two keys in the top right do the same for the right encoder. If you only have one encoder installed, you may disregard the keys for the location without an encoder). Layers work as-expected, so you can assign different encoder actions to each layer as well. The default assignment for the encoders as-shipped is volume control.
Please note that going forward, all Genesis orders are being shipped with the new Rev2 firmware installed. However, until VIA is updated, you will need to download the VIA JSON in step 1 above, as well as step 5.
Some fun ideas for encoder(s), now that they can be more easily changed:
]]>
We received the batch of Genesis about a week and a half ago. Upon inspection of the units, it was discovered that they included the incorrect rubber feet. Getting the correct rubber feet from our manufacturer will cause shipment delays, and we don't have a good ETA yet unfortunately. Usually, it takes about 1 week to get a package from our manufacturer, but we have not been informed of a ship date yet. Rest assured that they are aware of the issue and are getting a shipment of correct rubber feet from their supplier. If you would like your order shipped now but with the incorrect rubber feet, please see below as there is a solution:
Impact of Incorrect Rubber Feet:
The rubber foot on the left side of the image is the incorrect one. As you can see, the foot is designed to be mounted to a thicker plate. However, we do have a solution as we have rubber washers that fill the large gap.
Solution/Fix:
As shown above, we have washers on hand that fill the extra gap nicely. The image above shows the washers installed on the bottom of the base plate and the top of the base plate.
You can below see the slight difference in angle that results when assembled. Left side is the original feet and right side is the incorrect/alternate feet w/ washer.
Conclusion:
Please email us if you have read through the above post and want us to ship your order now with the *alternate* feet and washers! We are ready to ship these units ASAP.
We will keep those that want the original feet updated as to when those will arrive.
]]>Note: To enable the numpad layout, go to the "Configure" tab and select "Layouts" (on the left side) to enable the options that match your build.
If you are unsure what VIA is, please see their website here. It's a great piece of software that lets you configure your keymaps on the fly without needing to flash any hex files.
Note that you will need to import the keymap file each time you want to use VIA to remap Genesis, at least until VIA merges the pull request and begins to recognize Genesis automatically.
]]>We heard you guys loud and clear. Many of you commented 65% and 75% in the giveaway post and interest check form as your favorite layout, and there was decent amount of interest for a sub-$100 PCB layered keyboard design like the Genesis Macro Pad. It has been on our minds for a while now to design a bigger keyboard than the macro pad and our goal will be to make keyboard with a similar design language as the macro pad (RGB underglow, hotswap, rotary encoder, PCB sandwich design, etc). We will be reviewing the giveaway post comments and interest check form to decide what layout we will go with initially. Based on a cursory review of the data, it looks like we are most likely going with a 65% or 75%. Don't fret if your favorite layout of the two isn't chosen first; we plan on making more layouts as long as the interest from the community is there!
Above is a Kicad 3D render of the prototype USB 2.0 High Speed 4-port hub daughterboard. Much like the Drop CRTL, either of the two USB-C ports can be used to connect to your computer, while the second USB-C port allows the connection of other devices...like a Genesis Macro Pad, for example. Of the three JST connectors, one is used to connect to the main keyboard PCB, and the other two can support USB-A connector daughterboards (optional) so you can plug USB sticks and other devices into your keyboard.
We have sent out the hub design for fabrication and anticipate having prototypes within a few months.
One of our goals is to be the go-to supplier for custom PCB designs for mechanical keyboards, much like how GMK is the go-to source for custom/artisan keycaps. If you have a keyboard concept, it takes a synthesis of electrical, mechanical, and software skills to bring it to fruition. We want to take the pain of electrical design and make it easy. Right now, our cost to create a custom PCB design is feasible for group buys with minimum quantities of 100, but we are working on ways to further drive down our costs and enable smaller group buys, which we believe will allow even more interesting keyboard designs to exist. Some of the ways we are working to reduce costs and foster innovation include creative supply chain management, automation software, and providing a platform to better facilitate group buys.
]]>
You can check out the product page for more pictures and basic information, but I wanted to take a moment to draw attention to a few of the more subtle aspects of this product–the little bits of TLC we incorporated to take it from “just-another-macro-pad” to one that is surprisingly pleasant to build and use:
So clean your screen, clean your glasses, clean your mirrors, give them to your kids….whatever you like…you’ve got four of them in each kit.