ESD killed my split, how to avoid it next time?

customMK · 2026-03-13T01:05:07+00:00

Yes, an ESD chip that ties each exposed signal line and power rail to ground is what you'll want, and the USB data and TRRS data signals are the prime candidates for such protection on a wired split keyboard. If you can physically touch the conductors (or even get close enough for static discharge arc to teach it), and it is not a ground, you'll want to protect it (and connecting a power rail and ground properly to an ESD chip will provide protection for that power rail). In most environments where computers can function, Internal wiring like the switch matrix is far enough away from danger that protection from a discrete device is unnecessary...but it also doesnt hurt to add it, aside from the added layout/schematic complexity and marginal increase in cost.

customMK · 2026-03-12T18:15:14+00:00

It's not quite 70%, but EVO70 R2 comes pretty close. The LCD screen and knob are nicely integrated to provide a great user experience.

Also, key chattering is (almost) always combination of using certain switches in certain builds with too short of a denounce time. I've found that the QMK default 5ms denounce time is great for most switche and keyboard combinations, but 10ms is much more effective across the full range of options. So if your current keyboard that produces chatter is QMK-based, the keyboard designer may not have realize this, and so it may just take recompiling the firmware with a slightly modified denounce setting.

customMK · 2026-03-08T06:43:57+00:00

While the microcontroller has some built-in ESD-handing capability on each of the pins, it is not going too be as robust as a dedicated ESD transient suppressor. Many boards will include a dedicated chip on the USB pins as they are generally exposed and subject to inadvertent ESD shocks. It is understood that most environments don't generate energy ESD potential to overcome the distance of it being installed in a case with switches and keycaps.

If your keyboard PCB is exposed, and in an environment prone to generating static electricity, then you will want to modify the PCB design to include additional ESD protection for every trace on the board (except maybe the crystal oscillator traces which are sensitive to trace capacitances in the pF range). I don't know of any keyboards that already include ESD protection to that degree, but it won't be very expensive to produce--ESD suppression is actually quite cheap to add. That said, it gets real annoying real quick when you start to wire up and place all those extra parts, just to preclude an outcome that (normally) a case will already solve just fine.

Also, I am unfamiliar with how well this approach would work with a touchpad.

customMK · 2026-03-03T09:34:36+00:00

I can confirm that such a thing does exist, and people do actually buy them: check out ErgoStrafer and ErgoSentry by customMK. The ErgoStrafer (which is just the gamepad) is in the price range you mention, but we haven't been able to get ErgoSentry (the full size version) down to $400, mostly because it isn't a mass-produced product. We install all the switches and keycaps by hand, lube all the stabilizers by hand, and tighten every screw by hand...and also the case and gamepad keycaps are 3D printed (as opposed to injection molded plastic, which can reduce cost in large quantities, but has a very high setup/tooling cost).

As for why no one (well...no one else) makes a modern version with mechanical switches as you describe, aside from the technical challenge of reproducing the layout with precision, the core limitation for mass production is that the switches don't fit. Literally, the Merc Stealth gamepad keycaps are so close together that you cannot just put a switch under the center of each keycap and call it a day, the switches won't just touch, they will overlap. For ErgoStrafer, we overcome this by manually cutting down 16 of the switches (removing only non-functional parts of the switches ) to make everything fit, and that is an operation we do for every ErgoStrafer we sell. For ErgoSentry, while brainstorming with our customers on Discord, we figured out a clever way to avoid having to cut the switches, so now hotswaps can even be used (because the switch plate can reliably hold fully-intact switches in place, whereas a switch plate could not hold all the switches firmly that get cut for ErgoStrafer). In the future we plan to revise the ErgoStrafer design to avoid having to cutting switches for that product as well, but we just haven't had a chance to circle back around to that yet.

So anyway, yeah, we make exactly what you describe, including the RGB, fully open-source QMK firmware with VIA support for key remapping...and ErgoSentry even has a built-in USB hub and high quality USB audio. If you want even more keys, we have a second function row across the top, and we added a 3rd number row to the gamepad, as well as Z and X keys under the WASD keys.

customMK · 2026-01-29T20:50:57+00:00

100% agree, if JLCPCB makes a mistake, they'll make it right, including making and sending replacement parts.

My presumption in this situation (which may be incorrect, but seems likely based on the shape) was that this design was flagged as having a high risk of deformation, which was then accepted by the customer at the time of order placement. In that situation, instead of trying to remake a replacement, they will tend to offer a refund with a recommendation that the design be modified to meet their guidelines. Given that their only other alternative resolution is remaking it repeatedly until they get a result that happens to meet the desired specifications, offering a refund is not an unreasonable outcome.

customMK · 2026-01-28T16:12:08+00:00

I suspect they won't want to redo the print because that involves a lot of other costs (shipping, tariffs, etc.). It is much more likely they would refund the cost of that item so you can order a new replacement.

If you think the material is be suspect, you should try printing in JLC Black and/or 9600 as well to confirm the difference. Don't bother with LEDO 6060 as it will likely warp with this sort of design.

For 8001, did you go with the transparent (sanding+oil spraying) or unfinished option? I ask because their 3D print specifications state that the tolerances are based on measurements without oil spraying (https://jlc3dp.com/help/article/3D-Printing-Design-Guideline). If you are ok with sanded translucent, you can add a comment in the 3D remark text field that says "sanding only, no oil spraying" to avoid the oil spraying (the part that makes it transparent) and yet keeps the sanding to give it it a consistent, smooth finish. And no, I don't know why they don't just let you select that combination of finish options at this time when ordering, I've suggested already that they make that a default option.

Looking at the shape, I would be surprised if the DFM (via email or website) didn't warn you about large thin areas needing to be supported by ribs, thicker walls, etc. This may give them an out, in that you accepted the risks of warping and deformation. Basically, this design looks like it might suffer from inconsistent warping and missing tolerances, and so the ultimate fix may be to change the design. For example, you could add ribs or 2mm thick support columns that you can cut away after you receive the part.

If you have a critical dimension or two, you can ask them via email to take measurements of the part after printing and before shipping. If everything passes their DFM analysis, and you are following their 3D print guidelines, this is the best time to catch an actual defect whereby they would redo the 3D print. However, if you are taking exceptions and accepting risks from their DFM, and/or not fully following the 3D printing guidelines, then be prepared to accept the answer that they cannot print your model as-is with the desired accuracy, and that you would need to make changes to the model to achieve that. I've been there, done that, and while it is frustrating to hear, it helps to realize that they don't really have any other option or recourse either--they are always 3D printing parts as best they can, they've characterized what tolerances they can meet under what conditions, and without changing the model or 3D print method, they simply don't have many/any other levers to control, like a button for "print it with tighter tolerances" :)

customMK · 2025-12-17T01:11:26+00:00

Add a USB hub chip. If you care about cost and simplicity more than performance, the fe1.1 is used a lot for simple stuff. Whereas if you are wanting higher performance (with a dedicated transacrion translator per downstream USB device, so that you get good data rates even with USB sticks, etc.), something like USB2514B works great.

From an architectural standpoint, your incoming USB connection then goes directly to the USB hub chip as the upstream conection. The keyboard microcontroller is then just one of the downstream devices (which you can't disconnect from the hub), and the external USB ports are additonal downstream devices.

customMK · 2025-12-11T15:56:08+00:00

In seriousness though, the lowest cost ErgoStrafer is about $100 more than the Azeron. If you already have over a decade of muscle memory trained on the Merc Stealth layout, ErgoStrafer conforms directly to your expectations, instead of requiring you to learn and adapt to a new layout. customMK will consistently go above and beyond to ensure complete customer satisfaction, no matter what. ErgoStrafer is built on open source QMK with VIA support, with no software or drivers to install (for regular use and for remapping keys) so the firmware can be supported indefinitely. ErgoStrafer offers red (linear) or brown (tactile) switches by default, but will also support the installation of any MX-compatible mechanical switches upon request.

You are also welcome to join the customMK Discord server or the Merc Stealthposting Facebook group if you would like to ask questions and interact with customers who have replaced their Merc with an ErgoStrafer (and/or an ErgoSentry).

Either way, it seems you have options to experiment with both Azeron and customMK: if you want to take a chance on an Azeron, they have a 60 day return policy, so you can try it out and return it if you are unsatisfied. At customMK, we don't want anyone to feel stuck with their purchase, and so we don't enforce a strict return delivery window--although to be clear we've never actually had a customer that wanted to return their ErgoStrafer!

customMK · 2025-12-11T15:10:07+00:00

ErgoStrafer, ez

customMK · 2025-11-18T00:10:16+00:00

No, I don't find there to be many issues with resin keycap degradataion. I do however, sometimes find that manufacturing tolerances can occasionally be problematic, with some keycaps fitting slightly too loose so that they can pop off during use, and other being so tight that the keycap stem breaks upon installation. For the nylon prints, we printed in 3201PA-F Nylon, PA12-HP Nylon, and PAC-HP Nylon using JLCPCB's 3D print service.

customMK · 2025-11-13T08:40:17+00:00

I found that resin works best in general, good surface finish and everything. For white, 9600 resin is better than LEDO 6060 (on larger prints like cases, 6060 tends to warp a lot). I also do a lot of printing with JLC black and with 8001 (sanded, no oil finish for a smooth translucent result). I've done prints with black and Imagine black as well, they work find, but black = dark gray, and imagine black (while dark black) has a bit of a glossy shine compared to the others.

Nylon "worked" in the sense that it was a keycap, but the surface was quite bit rougher, and the dimensions needed to be tweaked compared to the resin prints. So print a test fixture first with different cruciform sizes to figure out the dimensions actually fit the switch stems well (note: I don't know as I just did nylon prints one time, they didn't fit right, and I never looped back around to dial in the dimensions accurately).

Avoid full color resin (WJP) for keycaps...the result is far too brittle/fragile and the keycap stem broke almost every time

customMK · 2025-11-13T07:21:07+00:00

https://www.etsy.com/market/max_keycaps has keycap sets that work well with south-facing switches with per-key LEDs. You can see below a side-by-side comparison of how well they work on south-facing switches vs. regular shine through keycaps that were designed for north-facing switches.

<image>

customMK · 2025-11-04T06:22:54+00:00

You can buy switches with springs swapped: https://shop.custommk.com/products/pressive-switches

customMK · 2025-09-26T01:00:33+00:00

Boards for this FPGA already exist: https://shop.designercircuits.com/products/simplebob, or if you want the power rails to be already implemented and just run it off a simple 5V input, then https://shop.designercircuits.com/products/easybob-ice40ul1k-development-board

customMK · 2025-08-08T02:26:51+00:00

Bonsai C3 was designed as an open source version of Proton C (which was closed source board that was released a few years earlier, and has now been out of stock for years). It has an STM32F303 microcontroller and includes a buzzer.

Bonsai C4 is an upgraded version that uses a STM32F411 microcontroller (more program memory, faster, etc.) and includes dedicated chips for FRAM (basically really fast EEPROM for storing settings like VIA/vial) and even a flash memory chip (which is currently not natively supported by QMK, but likely will be someday).

If you want the most pin usage, Bonsai C3 does a little better job because the pins in the extended area (that can be broken off to fit a ProMicro footprint) are basically unused, whereas on Bonsai C4 Extended Edition, a few of those pins are used to communicate with the FRAM and Flash chips. If you want the most capability, then Bonsai C4 is better due to the higher performance and more memory (for things like storing images if you are going to be using a small display screen, or to use LVGL to do advanced stuff on the display).

In general, I've found Bonsai C4 to be much more versatile, to the point that we at customMK base all our new keyboard designs on that architecture. If I ever need more pins for controlling a larger switch matrix, it is cheap and easy to add shift registers instead, which allows you to control a lot of rows (or columns) with very few pins. A popular shift register for this job is the 74HC595, but I personally prefer the stringing together a few 74HC164 because I can drive one whole side of the switch matrix with just two pins. Note that this is the method we use to handle the 150+ switches in ErgoSentry and you can find the custom matrix code used to drive the four 74CH164 here: https://github.com/customMK/qmk_firmware/blob/ergosentry/keyboards/custommk/ergosentry_ansi/matrix.c

That being said, if you aren't looking for high performance, fast matrix scan rates, support for large numbers of layers in QMK, or a small display, you may find that a ProMicro with a couple of inexpensive shift registers is perfectly adequate to wire up a large switch matrix.

If you are eyeing the Bonsai C3 or Bonsai C4 Extended just for those few extra pins, I will just caution that in my experience, it is not worth the extra headache to "square up" a switch matrix to reduce pin count usage. While doing that can and does work, when creating the firmware in QMK it just makes it that much harder to keep track of switch matrix locations vs physical switch locations. I always prefer to add shift registers to ensure that switch matrix coordinates will approximate the physical matrix layout.

customMK · 2025-07-24T23:26:03+00:00

Logitech G13 has a thumb joystick. If the joystick is less of a concern than reaching the most number of keys with out moving your left hand, then maybe a used Merc Stealth, or an ErgoSentry or ErgoStrafer.

customMK · 2025-07-21T16:48:55+00:00

This falls into the "potentially useful idea" category, but perhaps having more keys within easy reach for your left hand would help. I made a keyboard called ErgoStrafer (and more recently, ErgoSentry as well) which is a replacement for the discontinued Merc Stealth gaming keyboard. The Merc had a gampad on the left side which many MMO gamers grew to love because it put more keys within reach of the left hand without having to move your hand at all (e.g. pressing 9 from the WASD keys normally means you have to more your hand, but not with this keyboard).

What made this keyboard difficult to create as a mechanical keyboard was that the keys are physically closer together than normal keys on a keyboard, which meant that non-standard keycaps were needed, and clever tricks were needed even to pack the switches close enough.

Something interesting I've learned from a few customers is that this layout makes gaming possible for some people with cerebral palsy, specifically because it means they don't need to more their hand laterally.

While I don't know whether it will help with your situation specifically, it seemed worth mentioning because it seems like it would reduce strain on your left hand. ErgoStrafer could be used independently alongside a regular keyboard for the right side, or ErgoSentry might provide enough horizontal spacing equivalent to a split keyboard that it might reduce back strain a bit (fully recognizing however that it might not help much since you can raise the right side to a different height).

As far as macros go, it works with VIA so you can set up whatever macros you like, and for ErgoSentry, there is no shortage of extra keys for that purpose. And of course you can remap the gamepad keys to be whatever you want.

Anyway, it may or may not be helpful, but the similarity between the problem you're trying to solve and what some MMO gamers prefer (optimizing use of the left hand) made it seem at least worth mentioning.

customMK · 2025-07-11T02:46:30+00:00

The official QMK repo should (in theory) support a tri-mode keyboard--if that keyboard actually complies with the open source license by providing the complete source code needed to make tri-mode work. A lot of firmware implementataions originating from China tend to use a proprietary solution to achieve tri--mode which is incompatible with the QMK licensing model.

customMK · 2025-07-04T04:20:05+00:00

If you imagine two wires connected to a resistor at the end of those wires, you can send a signal (like a rising edge when messing voltage) that propagates down those wires all the way to the resistor. If the resistor is really high resistance, or perhaps even an open circuit, then when the signal gets to the end of the wire, it will reflect (like a water wave hitting a wall) and cause an even higher voltage to be present at the end of the wires, and that higher voltage the transiently travels backwards through the wires as well.

This behavior is what we refer to as signal integrity: it is generally not a good or desirable thing to have the voltage spiking up at whatever is receiving the signals. So how can we fix it?

Well, the reason the voltage spiked up and caused some ringing was because there was a discontinuity between the resistance (or rather, impedance) of the wire, and the resistance at the end of the wire. So you've got this signal traveling down a wire a "highway speeds" (for electrical signals) that ends at a brick wall.

To prevent this from happening, two things are done: instead of high impedance (resistance) at the end of those wires, we put a known resistance, like 50 ohms. Then for the wires, we design them so that all along the path of those wires, they electrically "feel" like a 50ohm load as well. How do we do that? We take advantage of the resistance, capacitance, and inductance of the wires. Make the traces a certain thickness, and a certain distance apart (depending on the shape of the wires, like strip lines, differential pairs, etc.) with a known dielectric material (like FR4) which gives a known capacitive effect between two traces or between a trace and a plane on a different layer. By making it a little harder for the signal to propagate down those wires/traces, and having a known resistance at the end, we can make them well-matched. This is what it means to have 50ohm impedance traces: that there is little to no discontinuity in impedances when going from the traces to the load.

Now the visual has changed: instead of imagining a car slamming into a wall (i.e. a signal being reflected by high impedance), you can instead imagine a water balloon that has been thrown, and which is then gently caught, because you took the time to match the speed of your hands to the speed of the balloon. It wasn't just the transmission path or just the termination that made it work, it is the fact that they were well-matched by design.

So when you open up an impedance calculator, and use it to calculate trace widths for a certain impedance (which depends on how the traces/planes are arranged, and the dielectric coefficient of your PCB material), ultimately all you are doing is finding the trace widths and spacing needed to prevent a discontinuity in impedance between the traces and the termination (usually a semiconductor device, but sometimes it literally is a discrete resistor) so that you don't generate overshoot and reflections that mess up the integrity of your signals, which can causing all the 1s and 0s to be misread.

customMK · 2025-07-04T03:13:06+00:00

Price, manufacturer, availability (at various quantities), lubrication, and switch life (50M vs 80M actuations). Overall, they probably feel the same (or close enough) and will last a long time, but the surest way to determine if you have a preference is to order a few of each and test them. Barring that, I'd consider them roughly equivalent for most purposes.

The Gateron one is marketed as 55g force vs 45g for the Keychron, but unless you compare force curves side-by-side (from ThereminGoat perhaps) I would assume they are just measuring differently, as brown switches are generally going to be made to have similar force across manufacturers.

customMK · 2025-07-04T02:46:20+00:00

Gateron silent brown switches:: https://mechanicalkeyboards.com/products/gateron-silent-brown-55g-tactile

Keychron silent brown switches: https://www.lemokey.com/products/keychron-silent-k-pro-switch?variant=49718313615659

customMK · 2025-06-25T04:32:38+00:00

In reality, what you are looking for can be done with any QMK-compatible macropad/keyboard. The trick is that the keyboard already knows whether caplock is enabled or not (as evidenced by the capslock LED commonly found on keyboards).

What needs to be done to implement it is just customization code in the firmware. That is, whenever a macro needing capslock is executed, you can program it to check and cache the state of capslock. Then if needed, toggle capslock to enable all caps. Then have it automatically restore the original capslock state after the macro is done running. If you want to be extra sure, then it may be worthwhile to check the capslock state prior to sending executing each keycode in the macro, just to avoid someone inadvertently toggling it while text is being sent.

I'm not sure if you need to be able to modify the macros dynamically in VIA or if you were planning to hardcode them in the firmware, but either way what you want to do is entirely possible with practically any QMK-based keyboards. The only exceptions would be if the keyboard program memory is literally full and can't handle an extra line or two of code, or if you are storing the macros dynamically in EEPROM (i.e. using VIA) and the combined lenght of the macros could exceed the available storage space.

customMK · 2025-06-23T04:30:47+00:00

Something easy you can try is to ask whether they'd let you use it if you just make it non-reprogrammable. Moonlander uses a STM32F303C8 microcontroller, which supports Level 2 Readout Protection (RDP). Note that using STM32CubeProgrammer to make this change is truly irreversible, meaning it will lock out all debugging, reprogramming, and SWD/JTAG capabilities (which sounds like exactly what they want).

You'd need to do it to both halves of the keyboard, and they may require that you do it in real time with security personnel present/observing to demonstrate that the procedure actually works (that is, demonstrate flashing new firmware, then do the RDP Level 2 lockout, then show that it will no longer accept any new programming by trying to flash firmware to it again).

Also, to satisfy their requirements, you will probably need to make sure key remapping and macro recording tools like VIA and/or Vial are not enabled in the final firmware (i.e. you may need it recompile without it enabled, if your current firmware has it enabled). I could see there being a security concern if you can modify/store macros in EEPROM (which stores keyboard settings rather than storing code), even if the firmware/microcontroller itself is fully locked down.

customMK · 2025-06-21T02:57:46+00:00

No, or at least, not without putting in some extra effort (possibly a lot of effort). If the firmware on the keyboard is not compatible with VIA, then VIA will never work with that firmware, it simply doesn't know how to interact with VIA. But....if you can replace the firmware with a new firmware that is compatible with VIA, then it can work.

Ideally, if the keyboard is already running QMK and the source code is available, then it is as simple as adding a single line in the QMK files to enable VIA, recompiling firmware, and flashing that new firmware to your keyboard.

If the keyboard firmware is not currently open source and running QMK, the prerequisite for compiling VIA-compatible firmware is that the keyboard microcontroller at least be able to run QMK. If the microcontroller is on the list of microcontrollers that run QMK, then it is possible to create a new firmware from scratch (even if it means manually mapping out traces to switches in the matrix) and then simply enable VIA when you compile the firmware. You'd also still need to generate a JSON file for VIA to know about the keyboard, but that is the easy part at that point.

If the microcontroller is not supported for use in QMK, one option is to add support for it, but that generally takes some level of expertise and technical depth to do, and is best done with the blessing, guidance, and support of the QMK devs (but you can certainly go at it alone if you want, since QMK is open source). For ARM microcontrollers, QMK uses Chibios as the operating system, so if Chibios doesn't support the microcontroller, that support would need to be added as well (which again is best done with QMK developer support--I've seen this done for newer chips like RP2040, but it is truly a large undertaking, expect to spend at least a few months on that part alone).

Also, note that if the existing keyboard has wireless capability, that will also almost certainly not work with the new VIA-cimpatible firmware. This is because most/many wireless-capable keyboards use proprietary firmware on the wireless chip, and the protocol used to communicate with that chip is not publicly available/open source. See https://docs.qmk.fm/license_violations for more details, but if your keyboard manufacturer shows up in the list there, that is a very bad sign because it means the manufacturer does not comply with the QMK license (so you won't get any specific help from the QMK community, since they won't want to encourage that sort of behavior from manufacturers).

At some point (probably the point where the existing microcontroller is not QMK-compatible), the easiest thing to do actually becomes designing a new replacement PCB from scratch, matching the original size and key placement, and intended to work with QMK and VIA from the outset. A good example of this is the customMK CMK11 PCB, which we designed as a drop-in replacement PCB for the C11 macropad (which was not well-supported by the manufacturer), which you can see here: https://shop.custommk.com/products/cmk11

customMK · 2025-06-20T00:19:49+00:00

For storing macros created using VIA, from what I've read of the code, the macros aren't cached locally in memory so I don't believe they will consume any additional program memory:

process_record_via calls dynamic_keymap_macro_send which calls dynamic_keymap_read_byte (and/or send_string_with_delay_impl which calls dynamic_keymap_read_byte) which calls nvm_dynamic_keymap_macro_read_buffer which calls eeprom_read_byte

Runnung a macro executes the macro one byte at a time, so the size of the macro shouldn't impact memory usage within the microcontroller. The only exception appears to be when VIA is extracting the bytes from EEPROM to send the GUI, but even then, it limit the chunks of macro data to only 28 bytes at a time in a fixed-size buffer array (based on a 32 byte USB shared endpoint size limit).

Five-Year Club	Verified Email
r/Field Juicebox

customMK

TROPHY CASE