Track Beast build log: a trackball Dactyl-manuform

Here’s my build log for a 4x6 Dactyl-manuform with an integrated trackball, which I’ve named the Track Beast (since everything has to have a name, and this is sort of a beast of a device).

Why do this?

As a long-time Kinesis Advantage user, I’ve been quite happy with the ergonomics of a split keyboard, but I’ve been envious of the features in QMK, the versatility of different key switches, and the more optimized key layouts in the DM and broader Dactyl family. Finally, I broke down and bought a 3D printer and built my first DM mini, a gift for my partner for her birthday (and partly a gift for me, to lure her away from her gaming keyboard with unholy MX blues….) It came out quite well for a first attempt.

A 5x6 / 5x7 Dactyl-manuform mini (almost like an Ergodox) with V2 Zilents and DSA keycaps

I started planning one for myself almost immediately — identical, but perhaps as a 4x6 so I could really lean into the ergonomics of not moving my wrists, . Then my mind was blown when I saw two recent keyboards on r/ErgoMechKeyboards: the Split Arcade by u/sbabborello and Dactyl-Manuform-R-Track by u/qqurn. The efficiency gain from the thumb cluster on a DM was great, but this pales in comparison to the ability to interact with a computer without moving my wrists at all. I messaged both of them to learn more. Ultimately I drew more inspiration from Qurn, and in fact my finished product looks closer than I would have expected (in the color, trackball placement, the QMK code, colemak, and even the trackball itself [which I already had]). Qurn’s gitlab fork of QMK is a huge asset to the community, since it supports multiple operational modes for the trackball and has fairly tight integration back to the keyboard… it saved me weeks over implementing this sort of thing myself.

Here’s a summary of what I built:

• 4x6 Dactyl-manuform mini with 5 thumb keys on the left and 3 on the right
• Outemu Sky Silent switches sold by u/hbheroinbob with DSA Skeletor keycaps
• 34mm trackball on a mount pulled from Qurn’s dm-r-track STLs (which itself I believe came from Ploopy models)
• Acrylic plates and LED underglow

Build log

Here are the parts I used (listed in order of use):

• Hatchbox black PLA filament for the case (color doesn’t matter for this)
• Outemu Sky Silent switches
• A bunch of 22 AWG hookup wire — I used solid instead of stranded wire because of the number of cuts in the insulation in order for the handwiring to work
• A bunch of 1N4148 diodes (one per switch, but consider getting extras in case something… happens)
• 2 microcontrollers (one per side); I chose an Elite-C on the master side (right) because it has extra pins for the trackball and a more robust USB-C connection. On the left, I used more traditional Pro Micro clones — I buy them in packs of 10
• 2 TRRS jacks; Note: you may want to avoid TRRS altogether… see below
• 2 buttons for resetting the microcontrollers (optional, but I already had a bag of these)
• PMW-3360 motion sensor for the trackball
• 3 steel dowels for trackball bearings
• 3 roller bearings
• Thin (1/8") acrylic sheet (for the bottom of the cases)
• 10 M3 threaded inserts, and ideally 2 M2.5 threaded inserts
• 10 M3 and 2 M2.5 countersunk screws
• TRRS cable
• WS2812B LED strip (10 LEDs, optional)
• Filler primer spray paint (any color)
• Automotive spray paint for plastic
• Enamel spray (for the top coat)
• 220, 320, 400, 600 grit sandpaper
• USB-C and micro usb cables (if you’re going with the Elite-C and clone approach)
• Trackball (I used a 34mm ball, but it’s a bit small with Qurn’s mount; suggest maybe 38mm)
• Transparent rubber pads for stabilization (optional)

3D printing the cases

There are a ton of DM forks out there. The one that I used as a base is u/DanL4’s DM mini fork, which accompanies his excellent build log. In fact, it’s this build log that encouraged me to get a 3D printer in the first place because of the care that he put into explaining the finishing process.

Locally, I made a few tweaks:

• Changing the layout to 4x6, which meant getting rid of the num rows
• Increasing the thickness to 3mm; Dan printed his with an SLA printer, which can go thinner
• Spacing was modified to better support DSA keycaps, which are shorter and wider; this changes the ideal curve as well
• Tweaking the screw posts, since 4x6 messes it up
• Changing the tenting (if I could do it again, I’d tent it even more)
• Using 5 thumb keys instead of 3, and making them all 1u (I forget if this is the default)
• Lowering the front and back left thumb keys about 1–2 cm; this is quite substantial, but I didn’t want these keys crowding the trackball on the right side. I kept it lowered on the left side to maintain symmetry

Then I added the trackball. This introduced quite a few hours of pain. Initially I tried to design one myself, but I quickly accepted that my life’s journey hasn’t granted me the skills to be a 3D modeler. Instead, I trimmed the trackball from Qurn’s additive STL. I had to remove the hotswapping additions, etc, which I did imperfectly. Qurn’s design is also using a 5x6, which means the orientation, etc would be quite different from what I was doing. I worked in Meshmixer, since I found it a bit easier to brute-force manipulate STL meshes rather than cleanly merging solid models.

You can see the extent of the brutality. In the finished version, I managed to close a couple gaps

When merging the two models, I tried to use Meshmixer’s boolean combine operation. Unfortunately that only works if the models are correctly shaped, which these were… not. I used Meshmixer’s “make solid” function to make it work, which did some horrific things to the integrity of the model but did allow me to move on.

Nooo where did my clean lines go?! Incidentally, note the presence of the grooves for the roller bearings and the hole for the motion sensor… this is the real value in Qurn’s model

With previous DM iterations, I’ve been very careful to pick high quality settings when slicing the models for printing (low speeds, thin layers, generous supports) such that it could take up to 50 hours per side. For this one, I just let my Ender 5 Pro rip at full speed with .2mm height layer height and build plate supports only for 65 degree overhang. No problems, and each side finished in 16 hours.

It’s a good thing, too… I had to print a number of iterations before I didn’t have any mistakes or merging artifacts.

A couple iterations. Sadly there were more than just these…

After printing, I sanded each side with 220 grit sandpaper, and again with 320 grit. I’ve started with 120 grit in the past, but I’ve found it’s done more harm than good.

After sanding one of the iterations. Note the flaws that came from messing with the model. A bit of hot glue can cover a number of sins…

After sanding, I took the cases out on my balcony and applied a couple coats of filler primer spray paint, then let it dry for a few hours. Filler primer is really important to get an even surface, especially for the curved segments. This is what allowed me to get away with faster prints — I found no difference in quality once the cases were primed.

After sanding the primed cases the first time. See below for an explanation of that weird left side

Once the cases were primed, I sanded again with 320 grit as well as 400 grit, washing the cases between each step. I wet sanded with 600 grit, then primed the cases and repeated the sanding. This time, I wet sanded up to 800 grit.

Once that was done, I spray painted my red layer. My parts list above references automotive paint for plastic, which is what I used for my partner’s board. It’s quite robust and has a good shine on its own. The red paint I used here was a cheaper, more general primer + paint, which dulled the finish and ended up being quite flaky. When I redid the left side, I applied two layers of enamel spray as a clear coat, which somewhat addressed this issue. Enamel spray is a good idea regardless, since keyboards see a lot of rubbing and bumping from use.

By the time I was done, the case doesn’t look like it’s been printed, and it’s quite smooth to the touch.

One thing I didn’t figure out is how to avoid dripping from the final red layer. You can also that the paint sprays thin — some layering shows right through

Wiring it together

I handwired each side. This was my 3rd time wiring a DM, so I was able to finish each side in about two hours with some minimal mistakes. It’s quite tedious, but I found it to be faster and neater if I solder diodes first, then solder columns directly to the switches, then rows to each diode. Diode orientation and connection to row or column is configurable… just be consistent for each switch. To keep wiring neater, I solder the connection to each switch as I strip segments of the wire insulation, sliding back the insulation towards the prior soldering point to minimize exposed wire. Some people like to simply burn off insulation, but the fumes are awful (and toxic?), so I get wire with a high melting point for its insulation and rely on stripping it instead.

Clean lines, but you can really see the abuse of that fast printing without proper supports and fine layers

One thing I experimented with was attaching the pin headers to the Elite-C and Pro Micro. Sadly, there isn’t enough clearance to use jumpers to avoid soldering wires right to the microcontroller, and this ended up being messier than soldering wires directly to the pads, compared to an earlier build.

Note: never go 18 AWG

There are different schematics out there for how to properly wire a Dactyl-manuform, but those are very dependent on layout. They were also thrown out the window for me once I added the motion sensor. There is next to no information out there about how a PMW-3360 ought to be wired to a Pro Micro (or an Elite-C, which is essentially a Pro Micro with extra pins… not that you’ll find any schematics to prove that). Here’s what I ended up with:

The pins for rows, columns, LED DIN, and CS / SS are all configurable, but the I2C and SPI pins are required in those positions. The exact wiring of the rows and columns doesn’t matter too much (even between the halves), as long as each switch is uniquely addressed by the matrix. I moved around my Elite-C wiring after the wiring pic was taken, but that’s a good representation of the right side; the left side simply has an extra row for the bottom two switches.

I don’t think there’s enough room on a Pro Micro to handle I2C, the motion sensor, and an LED strip, especially if you go larger than 4x6. I suppose one could switch I2C for serial and have enough pins, but I’m wary about things like LED support over serial.

The motion sensor is then done accordingly:

The PMW-3360 (presumably) needs to be placed particularly so that it can capture motion from the trackball, but Qurn’s mount already contained M2.5 screw holes and the hole for the sensor itself to see the trackball. The lens for the sensor additional contains a small ridge that catches on the edge of that hole, making the position easy to manage. Ideally one would have M2.5 threaded inserts in order to use M2.5 screws to attach the sensor. I had the screws, but not the inserts… so I did the unthinkable and hot glued the screws into the screw holes and onto the mount.

The TRRS jacks are wired using VCC, GND, and the two I2C pins. Keep it consistent between each half. Note that if using I2C between each keyboard half, on one side there must be 4.7k ohm resistors placed between each of the I2C pins and VCC. I find it easiest to place them right on the microcontroller, since there’s a fair amount of room there. TRRS has 4 wires, and going in the direction of tip-ring-ring-sleeve, it’s best to wire it as VCC, I2C 1, I2C 2, GND. Never expose VCC at the tip, or you’re setting yourself up to short the board early.

I recommend these keeb.io TRRS jacks ones over this more common digikey jack… they’re cheaper, and the grounding ring pops off the digikey ones at the drop of a hat. The main value in the digikey jack is that it’s larger and easier to work with. TRRS hasn’t been wonderful for me to work with — it’s common to find the keyboard isn’t working because one of the ends of the TRRS cable isn’t fully inserted. Next time around, I’ll use a different connector, or skip the connector and wire the microcontrollers together directly.

Both the microcontrollers and the TRRS jacks should be firmly attached to the case. The DMOTE was the only DM version that I saw had a good mounting solution for microcontrollers, and I haven’t seen any at all for TRRS jacks, so I’ve been hot gluing them to the side of the case. Another problem is that the case can be too thick for a USB cable to maintain a solid connection to the microcontroller (particularly for the Elite-C, which doesn’t have the socket protrude from its PCB). I ended up shaving off a lot of the case around the socket so that the USB cable can stay connected without being blocked by its own case.

When wiring the LED strip (consider one of the pics at the top of the build log where the keyboard is flipped), I like to wire each side with 5 LEDs with the strip split into two segments so that I can get better coverage over the thumb clusters. I also like to point the LEDs *down* rather than up to get better dispersal through the acrylic plates. It’s not very bright shining up through the key switches, but I’ve found that the acrylic plates do a decent job of refracting enough light to diffuse it more evenly across the switches.

Making the acrylic bottom plates

I really like the aesthetics of an acrylic plate; much better than printing a bottom that matches the outline of the rest of the case. I haven’t really worked much with acrylic, so it honestly took me ages to make the plates for the first build that I did. Much faster with this build! Here’s what I did.

Taking a thin acrylic sheet from Amazon, I placed each keyboard half on top and sharpied their outlines on the protective layer covering the sheet. When drawing the outline, I was generous with the edges, making the plate flare out from the casein most places and giving me breathing room to sand the edges and make corrections.

Then I took my dremel to my balcony, laid the (still covered) acrylic sheet on some cardboard and just cut out the plates from the outlines using a plastic cutting bit. A jigsaw would probably be a better tool for the job, but I’m in an apartment… I get what I can. There are a number of potential issues with cutting into acrylic, especially with a dremel — cutting too fast can cause the edge to melt, and it’s very difficult to get a crisply defined edge. However, the dremel gave me the capability to shape the plates around the odd thumb clusters. It’s quite difficult to make concave edges, though — I usually end up with a few marks in my finished acrylic where the dremel bit cut into the plate. So I just cut slowly and at a low speed and took breaks when the dremel got too hot to hold.

The edges were fairly sharp and irregular when I finished, so I peeled off the protective layers, washed the plates, and went back out on my balcony to sand the edges vigorously with 120 and 220 grit sandpaper. I especially dug into any concave corners so that I could round them out. Once I was happy with the overall shape, I used 320 and 400 grit sandpaper to really get the edges smooth to the touch. At this point it’s best to be careful. The edge of the acrylic diffuses the light refracting through it, and while a smooth edge will be clearer and more pleasant to look at, a slightly rougher edge will actually do a better job of diffusing the light if you’re not looking at it straight-on (which you wouldn’t). I chose to leave the sanding at 400 grit, which gives the acrylic a sort of dusty appearance.

Once I finished all this, I laid the plates at the bottom of the case and marked with a sharpie where I’d need holes to thread in screws. It’s important to do this after cutting out the acrylic plates, because these holes have to be in exactly the right spot. I took a drill and cut holes at a very slow speed. I’ve read that acrylic has a tendency to crack when drilled, but that hasn’t been a concern when drilling into the thin sheets that I’m using.

Note that the keyboard still has to be programmed (and most likely debugged) before attaching the case, but assuming that’s done, I used my soldering iron to push in threaded inserts to the screw posts and then screwed the plates to my cases. The screw posts are intended for M4 screws and I believe are threaded already, but M4 screws are ridiculous. A standard FDM 3D printer doesn’t have the precision to produce threads for an M3 screw, so I went with threaded inserts. The screws themselves should be countersunk, but I didn’t have any on-hand. After the screws were attached, I stuck on rubber pads to give the keyboard feet and to prevent it from sliding.

I didn’t talk about the bearings for the trackball, but I took my dremel with a metal cutting bit and cut the dowels down to the correct size before putting the roller bearings on it. Ideally I would have just gotten dowels of the correct length, but I have no idea what that is.

Configuring QMK

I feel like every keyboard should be using QMK as its firmware at this point. I knew I was missing out when I had a Kinesis, and indeed this is the best thing ever. I already had a layout warmed up from my first couple attempts at a build, but ultimately the basics were the same as the configuration for the DM in the codebase.

The changes that I had to make were enabling the RGB underglow (which is well documented), configuring the pin mapping, setting my keymap, and adding support for the trackball. One thing I did was split up my keymap files into two different directories, one for each side. This allowed me to define the row & column pin mappings for each side independently, and I could place trackball support in the right side without tweaking the left. The actual keymaps are shared between the two.

After I thought I had a reasonable keymap, I flashed the left side with the console enabled and configured to print the row and column for any key pressed. Plugging in just the left side (where normally the right side is the master), this a gives a simple place to make sure each switch is correctly soldered and connected, and confirms that the matrix & pin layout matches my expectations. The actual key output doesn’t matter yet. Doing the same thing for the right side, I was then ready to connect both sides together and give it a proper test run.

Every time I’ve done a build, there’s been something funky with the TRRS connection. This time, I had the sleeve and ring 2 swapped, so VCC and I2C 2 were swapped on one of the jacks. Amazingly, the RGB LEDs still lit up on the left side, so it took some debugging with a multimeter to confirm that the pins from each microcontroller didn’t match the rings on the other side of the cable.

After fixing that, I was able to plug in the keyboard and spend some time tuning the keymap to my liking. I then looked for the best QMK integration with the PMW-3360, and I found 2. This open PR for the Ploopy has an integration that seems fairly robust, but the context isn’t so helpful for someone integrating a trackball into another device. Qurn’s gitlab code feels a bit less elegant, but has its lifecycle events tied much closer to the keyboard that’s driving it. It even has support for different modes of translating trackball movement into arrow keys and the scroll wheel, which is pretty sweet. I ended up using most of the trackball code from that repo, which worked out of the box (except for setting CPI, which I still need to work on). Qurn spent a lot of time on triggering behaviors based on modifier key tap dances, which is super cool. I didn’t want to use that strategy myself, since I made a 4x6 and will need to make heavier use of layers. Instead, I just mapped the trackball configuration behaviors to those secondary layers.

I set up most of the modifier keys to be on the left thumb cluster, as well as space & backspace. The key to access the second layer (containing most of the number and punctuation keys) is also on the thumb cluster, while the third layer and alt keys are flung to the edges of the keyboard. The reduced thumb cluster on the right side has the left, middle, and right mouse buttons, as well as the various trackball modes.

Other notes from the build

How does it feel to use it?

I’ve only been using the keyboard for one day, during which time I learned how to use the keyboard by making this post. The stiffness of the Sky Silent keyswitches is probably the most awkward thing, followed by the mental translation required for pressing any of the number keys or punctuation. My brain has already remapped space & backspace using the left thumb cluster.

The trackball has been pretty easy to get used to, despite me never using one before. By default, the arrow and scroll functions are too fast to use without changing the CPI, so I’ve been relying more on the actual arrow keys. I’ll probably go back and have the CPI change depending on the mode. The main function of the trackball works quite well, but I’m using a 34mm trackball that’s just a hair too small; vigorous movement starts to bump it from its mount, which means that I can’t move it very quickly. Maybe as a consequence of the same thing, captured motion isn’t very smooth either, so mouse movements end up being jumpy. However, it’s sufficient so that I’ve been able to achieve my objective of not moving my wrists!

How about that left side?

A lot of the focus of the build is obviously on the trackball and its impact on the right side of the keyboard. I also spent a lot of time thinking about the left side: can I add more keys to it to take some pressure off of my right hand? Should I add more rows and columns to the left side? I tried that as a first attempt, but the asymmetry was pretty wild… much worse than navigating an extra column between two otherwise-equal DM halves. Should I expand the thumb cluster? I did that by printing a DMOTE left side. The DMOTE by Viktor Eikman has always been on my mind for an endgame build — exotic, and sacrificing norms for ergonomics.This was probably the most successful attempt — it has 7 keys in its thumb cluster and does this without sacrificing finger movement.

It was a *pain* to wire the DMOTE, enough to think that its author must seek some sort of thrill from frustration. I finished building it, but ultimately I had to scrap it for two reasons: the thumb cluster asymmetry was brutal, and (this was the deal breaker) the DMOTE wasn’t compatible with DSA keycaps. I had tried to modify the spacing in the model before printing, and I even tested 1/3 of the keycaps before wiring it… but I tested the wrong keys. You can see in the picture above that some of the keys didn’t even fit on the board, let alone with enough clearance to actuate.

Why did I pick these key switches?

I’ve spent my fair share of time looking at reddit’s mechmarket… I’ve seen what switches are in demand and I’ve looked at enough comparisons to get a sense for why someone would use certain sorts of switches. My goals are to have a quiet keyboard (if such a thing is possible with a mechanical keyboard) to keep things civil in the office, and I like a tactical feel to encourage me to not bottom out on each keypress. They’re also more familiar given that my Kinesis Advantage uses MX browns. I set up V2 Zilents for my partner’s board and really enjoyed their noise and tactility, and briefly set up Aliaz switches for one of my DM iterations, which are almost identical to the Zilents. I would have stuck with those Aliazs here, but I got sucked in by the in-depth analysis from u/hbheroinbob about the Outemu switches that he sells, hand-lubed.

These Sky Silents are purported to be even more quiet than Zilents (which they are) without sacrificing tactility (which is true). I also liked the idea of supporting a lesser-known switch maker, and they’re cheap. The main downside is that they’re much stiffer than I’m used to, but I’m hopeful that they’ll loosen up once I’ve spent some more time breaking them in.

What keycaps should I use?

I’ve been concerned about keycap layouts ever since I swapped my keys on my Kinesis Advantage: everyone and their mother in the mech keyboard community likes to use sculpted SA keys, but these make a lot of assumptions… like having uniform, flat rows. I like using DSA keys instead, because the keys are uniform (which is great for colemak / alternate layout users like me) and because they’re more tolerant to being pressed from the side, which can happen with a curved layout. Some people have tried to modify the Dactyl layout to support SA sculpting, but in my opinion that’s just working around the issue. I’d love to see more support out there for DSA, XDA, and other uniform keycap profiles!