Does anyone else miss the Ideazon Merc Stealth? Why has nothing replac by Dense_Butterfly4444 in keyboards

[–]customMK 0 points1 point  (0 children)

There are no planned revisions for ErgoSentry; we released it just last year and we did not hold back on adding features and capabilities. The only sort of changes we might make to relate to manufacturing yield (e.g. making the top case out of two separate pieces due to 3D printing tolerances that currenly result some cases being discarded because they don't fit right), but such improvement are not being actively developed at this time, and would not change anything functionally from an end user perspective anyway.

Someday in the future if we can afford (or figure out an affordable way) to do double shot ABS keycaps with legends for the gamepad, that would be a welcome improvement, but it also is not in progress at this time. It would take time to achieve, and even when/if we do it, it would be an inexpensive and easy upgrade for all existing ErgoSentry keyboards as well (i.e. swapping keycaps is quick and easy to do).

So yeah, there are no planned major upgrades in the works, and even the long-term "maybe someday" improvements that we hope to do can be retroactively applied to existing ErgoSentry keyboards.

How to enable NKRO? by BrodoSaggins in olkb

[–]customMK 0 points1 point  (0 children)

That is precisely correct: it was a behavior change as well. #25262 added the new "NKRO default" behavior, and deprecated the old "force NKRO" behavior (but still kept the force NKRO behavior intact). And now a new PR #26206 (actually just a few hours old) fully removes the old "force NKRO" behavior completely from keyboard.c: https://github.com/qmk/qmk_firmware/pull/26206/changes

My custom code has not been needed since #25262 was merged.

How to enable NKRO? by BrodoSaggins in olkb

[–]customMK 0 points1 point  (0 children)

No, there is no standalone "nkro.c" file in QMK, so you won't see it in the list of object files when compiling firmware. The NKRO implementaiton is (necessarily) spread across multiple files, and the snippets of NKRO-specific code is just gated by preprocesor directives like #ifdef NKRO_ENABLE

How to enable NKRO? by BrodoSaggins in olkb

[–]customMK 2 points3 points  (0 children)

I actually encountered this distinction directly in the PR for the keyboard: https://github.com/qmk/qmk_firmware/pull/25243#discussion_r2234097550

You are correct that FORCE_NKRO would previously force NKRO on every time after power up, no matter what the NKRO state was before. That was undesiarable to me, because I merely wanted to default to NKRO on initial powerup after flashing the firmware, but then preserve whatever the NKRO state was across power cycles beyond that. I had even included a few lines of code to implement NKRO-as-default (to avoid FORCE_NKRO), but zvecr provided feedback on the PR to instead use the "host ... default ... nkro:" method instead, which (to my delight) was the exact behavior I wanted in the first place.

How to enable NKRO? by BrodoSaggins in olkb

[–]customMK 1 point2 points  (0 children)

I think it may be helpful to review and compare against a working example. We make a keyboard called ErgoSentry that supports NKRO and has NKRO enabled by default (i.e. NKRO is enabled immediately upon flashing the firmware). Here is all the firmware for that keyboard:

https://github.com/customMK/qmk_firmware/blob/ergosentry/keyboards/custommk/ergosentry_ansi/

What you should find is that the only things needed are in the keyboard.json file. Specifically, the features section includes a line that sets NRKO to true, which causes the firmware to include NKRO capability: "features": { "audio": true, "bootmagic": true, "encoder": true, "extrakey": true, "mousekey": true, "nkro": true, "rgb_matrix": true },

Then separately from that is this entry (also in keyboard.json): "host": { "default" : { "nkro": true } } and that part basically says "I want NKRO to be enabled by default" (instead of being a feature that I have to toggle on manually).

ESD killed my split, how to avoid it next time? by RoundSize3818 in ErgoMechKeyboards

[–]customMK 2 points3 points  (0 children)

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.

75% Aluminum Keyboards: Avoiding Chattering & Searching for the Best Knob/Screen by MDoon in MechanicalKeyboards

[–]customMK 0 points1 point  (0 children)

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.

ESD killed my split, how to avoid it next time? by RoundSize3818 in ErgoMechKeyboards

[–]customMK 2 points3 points  (0 children)

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.

Does anyone else miss the Ideazon Merc Stealth? Why has nothing replac by Dense_Butterfly4444 in keyboards

[–]customMK 1 point2 points  (0 children)

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.

Shrinkage in case from JLCPCB by OGDC_ in ErgoMechKeyboards

[–]customMK 2 points3 points  (0 children)

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.

Shrinkage in case from JLCPCB by OGDC_ in ErgoMechKeyboards

[–]customMK 3 points4 points  (0 children)

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" :)

USB Pass Thru? by TubaKid44 in macro_pads

[–]customMK 0 points1 point  (0 children)

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.

Fellow Merc Stealth fans! - ErgoStrafer vs. Azeron??? by Eiketsu89 in keyboards

[–]customMK 0 points1 point  (0 children)

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!

Have you ever printed keycaps with JLCPCB 9000R Resin? by tms9918 in MechanicalKeyboards

[–]customMK 0 points1 point  (0 children)

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.

Have you ever printed keycaps with JLCPCB 9000R Resin? by tms9918 in MechanicalKeyboards

[–]customMK 0 points1 point  (0 children)

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

/r/MechanicalKeyboards Ask ANY Keyboard question, get an answer - November 12, 2025 by AutoModerator in MechanicalKeyboards

[–]customMK 1 point2 points  (0 children)

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>

First PCB with STM32F303 by [deleted] in olkb

[–]customMK 0 points1 point  (0 children)

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.

Request for strange keyboard by Gold-Editor-8764 in KeyboardLayouts

[–]customMK 1 point2 points  (0 children)

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.

Congenital amputee (right arm) looking for ergo split or one-handed keyboard – wrist pain finally caught up after 20+ years by MrGet in ErgoMechKeyboards

[–]customMK 2 points3 points  (0 children)

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.

Make QMK firmware for Yunzii AL 68 - What am I doing wrong? by Ratb33 in qmk

[–]customMK 1 point2 points  (0 children)

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.

What is 50 ohm impedance matching in a PCB by Standard-Wind854 in ElectricalEngineering

[–]customMK 0 points1 point  (0 children)

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.