## The Problem with Mechanical Switch Reviews

HaaTa
Master Kiibohd Hunter
The Problem with Mechanical Switch Reviews

Like most of you, I take keyboards way too seriously. However, unlike most of you, I’m an engineer. This means I need facts, data, and real evidence before I can form an opinion. And this lack of actual information has always bothered me when it comes to how the keyboard community at large tends to review switches.

Here is an example of a review I see quite often:
“Switch X feels amazing! Switch Q is better than Switch Q2. Just add some lube and switch Y will be great. Even NIB switch Z feels like typing on wet newspaper. OMFG, you like switch Q more? You...you heathen!”

What’s similar about all those subjective comments (and that I’m sure you’ve also seen if you’ve read enough about keyboards), is that they say really nothing at all.
Qualitative analysis makes for a good sounding review. But does it really mean anything at all? How do you know their tastes match your tastes?

Spring weights brings a little glimmer of hope to me when it comes to measurable details, but summarily falls over, like a pile of nickels. As spring weights can vary wildly between two similar switches. And it certainly won’t tell you if one switch is scratchy or fresh from the factory.

On that note, does anyone believe that gold springs do anything?! If claims are being made that they are better than non-gold springs, doesn’t anyone worry that they are being taken in by the same sort of marketing that Monster cables uses?

But this isn’t a critique of mechanical keyboard switches and possible customizations and how to compare them. It’s my exploration of of what really matters to all of us. Tactility.

Tactility
I’ve always been fascinated by tactility. Ever since I can remember, I’ve loved pushing buttons. Not only because I wondered what they did, but I wanted to know what they felt like.
This is absolutely a major part as to why I’ve continued my fascination with keyboards. For something that can be so satisfying, why is it that some keyboards can feel so amazing and others....so terrible?

Is it all subjective? Or can we achieve some semblance of objectivity?

This question of ‘why’ is the reason I’m part of the keyboard community and the reason I decided to embark on the humble task of building the Keyboard Force Curve Gauge.

What’s a Force Curve Gauge?
Put simply, a force curve gauge is a device that records a force while changing the distance into or away from a starting position. This data can be represented in a force curve graph. For example:

The legendary IBM Model M, circa 1989. You can click the graph to go to the plotting website where you can select to overlay the other 3 press/release lines.

(https://en.wikipedia.org/wiki/Buckling_spring)

In general force curves have either one or two lines. The lines are read from left to right, where 0 mm is where the press begins. The press ends where the force seems to go up to infinity, also known as bottoming out (usually around 3.5 mm and above).

The first line, blue in the above graph, is the press. Initially there is a steep increase in force, where if you were pressing the switch are taking the spring force away from the switch housing and transferring it onto your finger. Likely the most interesting part of a buckling spring switch to look at is its tactility. From the graph above (and below), the tactility corresponds to the sharp drop in force at around 1.8 mm.

The second line, orange in the above graph, is the release. In most cases the release force curve is different than the press. This is known as hysteresis.

With force curves you can now compare the feel of different keyboard switches visually! Hopefully someday we can stop qualifying keyboards with descriptors like “feels good” or “buttery smooth” and put some actual numbers and data behind the sort of keyboards we like. Keyboards are like shoes and everyone has their personal preference. There is absolutely no reason why we should be forced to use some poorly thought out “one-size-fits-all” solution.

History
Force curves aren’t anything new. Like the IBM buckling spring curve above, we’ve seen them in keyboard switch patents and on manufacturer websites for a long time.

(Burroughs Opto-Electric - wiki/Burroughs_Opto-Electric)

(Fujitsu Leaf Spring Gen2/3 - wiki/Fujitsu_Leaf_Spring)

But these were just engineering approximations of what the force could or should be, they are not extensive set of repeated field tests.

Early Force Curves
While living in Japan (back in 2009/2010), and still a novice in the ways of keyboards. I stumbled upon Atelier Silencium (http://www5f.biglobe.ne.jp/~silencium/k ... index.html).
This Japanese keyboard wizard, SPARC, had *real* force curves, measured for all to see!

All I could think when I first saw this crazy graph was “Woah, this is so awesome.”

(http://www5f.biglobe.ne.jp/~silencium/k ... isoku.html)

Why can’t I do that too?
Fast-forward to early 2012. By this point, I’d already amassed quite an interesting collection of nearly 200 historical keyboards (and keyboard switches) but I had a “problem”. I’d started to find switches that no one had ever seen before (in the keyboard community). Since I’m not prone to hyperbole and marketing speak, there was no easy way to truly describe how they felt.
I started thinking about what it would take to measure switches and accurately communicate my findings, but I really had no idea what sort of apparatus was required.

Some months went by, and I had a chat with user OO2 and he had recently acquired an Imada force gauge, with the intent of measuring Topre switches. Unfortunately he didn’t have the data logger or a stand to mount the force gauge.
I said, “Hey! Send it to me, I’ll make you a data logger.” (and I still have it, sorry OO2…).

So, that’s what I attempted. The original code is still up on GitHub (https://github.com/haata/imada-rs232c-teensy2-hid).

Then, as most of us do, I got busy (something about riding my bicycle across Japan for 3 months then driving a U-Haul full of keyboards from Toronto to NYC to San Francisco). Needless to say, the project was shelved until I got settled into my new place.

Force Curve Gauge v1
In late 2013, I was scrounging through HSC (Halted for those in the SF Bay Area) and noticed something interesting. It was a small arbor press that looked something like this one

And as all great ideas do, the design for Force Curve Gauge (v1) was born.

The big problem that was blocking me before, was finding a way to mount the force gauge on something sturdy enough to take good readings and measure distance at the same time. It’s correlation between force and distance that is important here. The most sophisticated force sensor will not give you the force profile of a switch. Without the tight mapping of force vs. distance, the generated force and distance data would be inaccurate.

This is why a force curve gauge must have at least two measuring sensors: one for force and one for distance.

My materials.
Now in my typical style, I reverse engineered the iGaging DRO (with much help from this link http://www.shumatech.com/web/21bit_protocol?page=0,1) so I could read it directly. This is important as you want the force reading to be timed as closely as possible to the distance reading.
Force, I used the Imada serial interface.
Since the Arbor Press is a manual device, I programmed the Teensy to use each distance tick on the DRO as a trigger to read the force gauge and output a new data point.

And thus, v1 was born:

photos-f62/some-teasers-of-what-s-to-come-t7411.html

A special shout-out to jacobolus who helped me measure a number of switches. Unfortunately, v1 had some fundamental issues that really couldn’t be remedied.

Some of the graphs that jacobolus helped measure/analyze (notice how the release curve is omitted, it wasn’t accurate at all): Problems with v1

See that long transfer bar. Well, that deflects a bit...and skews measurements whenever you change directions. Sure, it works well when measuring a key press, but good luck getting any kind of decent key release measurement.

The other main hardware problem was that it’s really really hard to move an arbor press at a consistent rate. Due to how slow the force data was being polled from the Imada force gauge, I found that it was difficult to reproduce force curve results. If I sped up during the tactile point, sometimes I’d miss possibly important details in that test run.

Take for example, this Model F Buckling Spring force curve that I measured very early on.

(Model F - photos-f62/some-teasers-of-what-s-to-come-t7411.html)

Next, using the same v1 force curve gauge, but measuring more carefully.

(Model F - https://geekhack.org/index.php?topic=56828.50)

And finally, what I’ve been able to measure consistently using the v2 force curve gauge.

Let’s be honest, the first graph is awful and just plain wrong. And that’s why it’s important to have a tight correlation between the force and distance data. Otherwise you don’t have anything useful at all.

And, well, I didn’t like the firmware architecture. The serial port was too slow (it wasn’t synchronized well enough with the DRO). It was all polling based, and if any of the devices got into a bad state the firmware would hang and corrupt the test :/

Anyways, I got a bit discouraged, and shelved the project while I searched for a proper force gauge stand.

eBay Awesomeness
A few months later, I, like OO2 before me, located a great deal on an Imada force gauge of my own. Only this time it was a newer version with a faster serial baud rate! (19200 vs. 2400).
This rekindled my excitement in searching for a way to build a better force curve gauge. It’s the Imada DS2-1 (the last non-USB version as far as I can tell).

eBay Annoyances
Normally I don’t call out my eBay horror stories, but I think this one deserves some notice.

By some luck, I’d managed to locate an official motorized (consistent movement!) Imada force gauge stand on eBay for a pretty reasonable price (sub \$500). I won it (along with a couple other items from the same seller), paid quickly (as I usually) do, then waited for my force gauge stand.
I waited.
And waited.
Waited some more.
Fed up, I sent a message to the seller, and they responded back that they’d been in some car accident or something. Ok, whatever, I don’t need a refund, just ship me the stand.
Some more weeks go by, I send another message.
Nope, still nothing.
A couple more weeks go by, and I’m getting worried, so I open a case, and explicitly indicate I want the item.
A few days later, ****, I get a refund.
Bah, that was a waste of time.

Searching for a force stand
By this point, I was pretty fed up with eBay (pretty slim pickings for force gauge stands that would work with an Imada gauge and that I’d be able to modify significantly).
So, I started looking at new chinese made ones.
They were a bit pricy, about \$1000 shipped at the time, and I knew I’d have to gut the thing. But that’s still cheaper than the \$10k+ for new official motorized force gauge stands.
And so, this one arrived!

DSC_0862

DSC_0864

Now that I’d acquired the critical pieces (force gauge and stand), it was time to design v2.

Building v2
Parts list for for Force Curve Gauge v2.
I have a full album of pictures on Flickr: https://flic.kr/s/aHskgDhUb2

Assembly
The mechanical assembly was mostly straightforward. Just had to drill some holes in the steel casing of the force gauge to mount the iGaging DRO as well as a couple holes for extra cables going to the teensy.
Conveniently, I could use an L-bracket to connect both the DRO and the force gauge head. This has the benefit of being extremely sturdy, so I won’t have to worry about any mechanical distance drift!

DSC05322

The tricky part was definitely connecting all the different electrical components to the Teensy. As usual, I wanted to be ambitious. I needed to be able to automatically stop the force test stand head whenever the force was above ~800 gf or I risked destroying the load cell located in the Imada force gauge. The test stand had no such functionality built in of course (it can’t sense force by itself, nor connect to gauges). So, this required modifications to the otherwise closed system of the test stand.

I wasn’t quite ready to design a new PCB, so I pulled some tricks out of my keyboard protocol reverse engineering bag

DSC_0891

Hey, isn’t that a PIC microcontroller? This *was* the brains of the force test stand. Even better, is that it’s socketed! So, I just removed it, and inserted my own custom socket with wires attached to all the pins that I determined were useful.

DSC08014

DSC08015

Obviously, I didn’t have a schematic, so I had to trace all the pins to their individual functions and figure out what the PIC was doing to control the force test stand.

Currently hooked up to the Teensy 3.1
• Motor control
• Top/bottom limit switches
• Imada force gauge serial port
• Imada force gauge analog output
• iGaging serial output
• Continuity tester (used to determine press/release of contact switches)
Rather than bore everyone with the intricate details of the microcontroller firmware design (which you can find here: https://github.com/kiibohd/force), I’ll focus on the main design decisions.
1. No matter what, make sure the force gauge doesn’t destroy itself (highest priority interrupts on limit switches).
2. Reading force over 800 gf is bad. So if detected, automatically move the force gauge upwards.
3. Readings from sensors should occur as frequently as possible, asynchronously.
5. Clocking sequence for iGaging DRO should be generated by hardware and not depend on cycle counting GPIO sequences.
6. Data output to the PC should occur as frequently as possible in remaining spare CPU cycles each with a precision timestamp (ideally per CPU tick).
7. Separate data output and control input
8. Use debug cli for commands
9. Use USB Vendor Specific endpoint to transmit data to PC
10. Include a test mode to repeatedly press a switch, then release, go to the reset position and test again without any user intervention.
12. Speeds up measuring switches considerably.
The goal was to design something that could record as much data as possible so the possible drift between distance and force measurements were minimized as much as possible.

My goal was to be somewhere around Imada’s latest gauge (http://imada.com/products/zt-digital-force-gauge/) where it touts 2000 data points per second.

In practice, I’m about to get around 9500 points per second from USB. The ADC values (which I’ve tuned for accuracy rather than speed) samples about around half that speed. Somewhere around 5000 data points per second. 2.5x speed improvement over the latest Imada force gauge, not bad at all.

FINALLY, I am able to enjoy raw force curve data!

Sadly, this is where the scientists reading this will empathize with my pain. It turns out that gathering raw data is easy. Making raw data into something useful is much harder than collecting the data in the first place...

Data Analysis
This is one of those times where I was really glad I half paid attention during my lectures back in college on computational analysis. I’m not terribly good at the subject but using my vast knowledge of keyboard switch curves I’ve been able to produce something significantly better than what I’ve seen so far.

(I’m always looking for suggestions on ways to improve data analysis. Even better if you’re familiar with numpy. https://github.com/kiibohd/force/blob/master/fcv.py)

Each set of raw force curve data file is accompanied by a json file which contains things like Vendor, Part number, description, author, max force bounds for graph, and tweaks for when the Python algorithms get a tad confused.

Due to how I had built the force curve gauge, the raw data that I receive from the sensors are not zeroed. This means I do not know where the start or end of a keypress is within the data. Yes, it might be possible to zero out some axis before a test, but actually determining the position by eye to 0.1 of a mm is rather tricky, if not fruitless.
Therefore, much of the data analysis focuses on trying to determine the start and end of a keypress. Using a few heuristics, plus a few plot specific hints and adjustments, we have some rather nice graphs.

Start of Press
Determining the start of a keypress is a lot more difficult than it sounds. In most cases it’s sufficient to use a peak detection algorithm to detect the switch pre-load force (the initial jump in force when the load cell contacts the keycap). From the peak, then I trace back until the force is consistently ~0 gf and use that as the start of the press.

This is an ideal case. Unfortunately, it’s also possible to have switches that do not have an initial peak. I don’t have any measured yet, but take a magnetic spring without any pre-load. It would look something like this.

(http://cdixon.org/2015/05/12/exponentia ... en-sudden/)

Once I locate the peak (which is the end of the press), then trace back, it becomes rather difficult to really determine where the start of the press was. Currently I have some manual configuration options to get around this issue, but it is something I’d like to solve in general for all keyboard switches.

End of Press
While not as tricky as the start of press, this is still a difficult point to be absolutely certain of. When the force curve gauge hits a certain force (around 800 gf) it will automatically change directions. Each raw data point is accompanied by a direction, which makes the direction change point easy to find. However, what we are really interested, is when the switch for “starts” to look like it’s going to infinity. We need to record the force right up until the switch plunger stops moving.

Here’s a good example of an asymptotic bottom-out force (looks like is going to infinity).

And here’s a curve where you’re not quite sure if it’s going to infinity yet (as the distance value is still changing).

This is particularly important, because the press and release data may be slightly delayed due to stand mechanics, test fixture sturdiness, load cell creep recovery (we are changing the force direction and trying to get a reading immediately afterwards), and a caliper distance reading (delay in directional change). To combat this, I align the press/release force curves based on their bottom out sections.

After many weeks playing with various algorithms (I wanted to auto-detect the distance scaling of the graphs), I gave up. I still think it’s possible (especially for constrained cases such as the Outemu Brown switch above) to determine the bottom out points.
Fortunately, in practice the bottom out curve is rather easy to align visually, so this isn’t really a large problem right now.

Averaging Force Points
One interesting visual issue is that there are more force data points than distance data points. This means each distance tick has more than one force attached to this.
Currently, I apply averaging to those duplicate force points, which helps smooth out the force curves.

Another option was to use the time parameter, in addition to the constant speed, to infer distance points and make the graph even more precise. While this is still possible, I started to run into Plotly limits when using the full dataset (had to upload using their Python API rather than directly through the web interface) so I decided not to pursue it.
I’m also not certain that getting greater distance precision is useful at this stage.

Raw Distance to mm
Rather than convert each distance tick from the iGaging DRO inside the Teensy 3.1, I opted to record the raw distance value and convert it later while generating the graph. The main benefit to this is that if I discover an error in my conversion I don’t have to re-measure all the switches, but just update the graph from the same set of raw data.

For a detailed explanation, please refer to the code comments here: https://github.com/kiibohd/force/blob/c ... cv.py#L693

Raw Force to gf
When designing v2 of the force curve gauge, I included a “calibration test” before actually recording the press/release data.
The way this calibration method works is by stopping every 0.05 mm or so (5 ticks) and recording both a serial force reading and an ADC force reading. We have to stop because the serial force reading is buffered and may lag the ADC reading significantly.
In addition, the serial reading will affect the ADC reading (likely due to noise within the cable), so the readings have to be taken separately and cannot be done continuously.

Using this calibration data, the intent was to generate both press and release ADC conversion factors for each full test cycle as part of the raw data. The hope was that this would combat against possible variance in the load cell behaviour.

Unfortunately, the serial force readings lagged far more than expected. In some cases this just lead to garbage data. And a nonsensical set of conversion factors.

After about 3-4 weeks of trying to figure out a solution, I decided that I needed to move forward. It was time for a magic number (hah!).
https://github.com/kiibohd/force/blob/c ... cv.py#L386
This number was tuned after measuring numerous Cherry (and Topre) switches. It is calibrated reasonably well, but this is definitely something that could use improvement.

Noisy Data
Anyone that’s worked with raw data before, knows that noisy results are just another thing you have to deal with. In particular, the distance sensor often seems to jump around a little bit (i.e. go down when the motor is clearing going up).
To work around this I’ve added some data adjustment to force sequential distance ticks.
https://github.com/kiibohd/force/blob/c ... cv.py#L779
If 3 of 4 data points are in one direction, force the last one to be in that direction as well.

Analytics
As of writing this article (2016-11) I have added two different analytics to these force curves: Total Force (gfmm) and Actuation Force (gfmm).

gfmm
gf or gf is the measurement of gram-force or the mass of one gram due to the gravity of Earth. Another similar unit is cN or centi-Newton, it has a slightly different scale, but means the same thing. As it’s a bit easier to understand (and more common), I’ve standardize on gf as the common unit of force.

mm or millimeter is a unit of measurement. But most of the world already knows that.

gfmm or gf x mm can be read as the amount of force (gf) exerted over a distance (mm). In the context of force curve graphs, this is simply the area under the force curve from one point to another. This measurement, while very difficult to calculate without a force curve, is quite useful when trying to compare switches together.

Total Force
Total Force (gfmm) is the area under the press force curve from 0 mm to bottom out (4 mm in the graph below). Using numpy I’m able to use the dataset to calculate the total area under the force curve.
https://github.com/kiibohd/force/blob/c ... cv.py#L540

We can use a little bit of high school math to calculate the Total Force of a switch.

$\int_{start}^{end_{bottom-out}}f_{force}dd_{distance}$

For those who don't remember what that means. We just multiply the force at every point between 0 mm and the bottom-out position (e.g. 4 mm). More simply, this can also be read as the area under the force curve.

$f^{force} \cdot d^{distance}$

Which can also be read as our force unit.

$g^f\cdot mm$

Actuation Force
The term Actuation Force is often incorrectly used for Force at Actuation (63 gf below). As Actuation Force really means how much force did it require in order to activate the switch (gfmm). So, just like Total Force we take the area under the force curve, but from 0 mm to actuation point (5.6 mm below).
https://github.com/kiibohd/force/blob/c ... cv.py#L549
Unfortunately, it’s not always easy to measure the actuation point on switches. Contact switches are straightforward. However capacitive and magnetic switches tend to be a lot trickier to get the precise actuation point. If you’re reading a graph and it’s missing the Actuation Force, it generally means that recording the actuation point wasn’t easy to do.

Plotly
Rather than just export boring png files for plots I wanted something more interactive. And while I was working on raw data processing I discovered Plotly (https://plot.ly/).
At a basic level, it provides interactive graphs (including various export formats, such as png). Remember that you can click the graphs in the post to play around with them on the Plotly site, as they can’t be fully embedded here. But what’s even more interesting is that it provides the dataset along with the graph. This means anyone can take the force curve data and apply new algorithms to it or even compare it to force curves they’ve generated themselves.

However, the most important feature for me is the ability to update force curves in place. So for example when I add a new analytic, I can update all the force curves in place while keeping the same link as they have today.
As a quick note, the two dates present on each graph are: normal font is measuring date, bold font is the latest updated date.

For all it’s awesomeness, Plotly is a bit finicky. I’ve spent tens of hours adjusting the templates to work correctly across all the different force curves. I’m also not able to do the sort of tooltip annotations I’d really like to have yet. But I’m hopeful that Plotly will be adding these sorts of things in the future.

Future
Even as the force gauge stands right now, I still have some improvements planned. It shouldn’t even require any hardware changes.
• Varying speeds and changing acceleration
• More curve analysis (additional analytics)
• Automatic graph annotations (start of press, bottom-out point, pre-load force, etc.)
• More precise distance measurement (perhaps through timestamp and speed analysis)
I still don’t know what the Kiibohd Force Curve Gauge v3 will look like or when I’ll start building it. But I have some ideas

Conclusions
To be blunt, most keyboard switch reviews are relatively useless, and you really need to try switches for yourself.
However, it is possible to extract real, and useful, quantitative information about keyboard switches. It is just that all the current methods (nickels, spring weight, actuation force) don’t really give you a basis to compare against other switches.

What I’ve tried to do here is inspire a bit more engineering rigor into keyboard switch reviews. And, just maybe, we can start using useful metrics such as gfmm instead of just gf @ mm.

Still, I think we can do even better than this. This is just the beginning, and I hope all of you feel that way as well.

If you feel like reading even more. Some useful links on various topics. Input Club link: https://input.club/the-problem-with-mec ... h-reviews/
Last edited by HaaTa on 20 Nov 2016, 19:39, edited 3 times in total.

ohaimark
Kingpin
Good stuff, HaaTa. Good stuff.

livingspeedbump
Not what they seem
This is a very needed article. I can see this getting referenced many, many times in the future.

Thank you for this

XMIT
[ XMIT ]
Great article. Unlike many of us, you're an engineer *with free weekends*.

We chatted off line about quantifying scratchiness. Any progress with that? The way I see it if you take a completely linear switch (like Cherry MX Black) you can draw a best fit line (1st degree polynomial) through a chunk of the data and the calculate the mean and standard deviation of much of the data. At some point you can say that a switch is "smooth" or "scratchy" based on some threshold value of standard deviation.

Maybe I'll do this myself looking at some detail data. A good reference would be the trivial non-switch: just a spring's force curve (or a little platform supported by 3-4 springs for stability).

ohaimark
Kingpin
I found that piezoelectric pickups are great for picking up scratchiness because you can see the raw audio frequency vibrations.

I don't have a machine that presses switches smoothly, consistently, and quietly. That makes my results less than ideal, unfortunately.

webwit
Wild Duck
Great stuff! Is this open data, and if so under what license?

ohaimark
Kingpin
It's open enough to go on the wiki. I spoke with HaaTa about it and we're going to work out a system that keeps his graphs up to date and on the wiki once the DTAs wrap up.

webwit
Wild Duck
There are plenty of graph extensions for mediawiki, some can import csv etc.

HaaTa
Master Kiibohd Hunter
Yeah, if we can somehow link mediawiki to plotly, then when new analytics are ready the graphs can auto-update. I'm no webdev so I'm not sure how hard that'd be. But yeah, if something I can do makes it easier to add into the DT wiki, I'm totally up for it (as long as it can be automated ).

License wise, I only have one rule: Please link back to the original content (in this case, the plotly graph) so others can find more of the graphs. Otherwise please share/modify/extrapolate
Does something like a CC BY-SA work?

Also, plotly also has csv'ish data for all the graphs. I think I've set it all to public, but please contact me if it isn't (because it should be open). Most of the plotly libraries are open as well: https://plot.ly/javascript/open-source-announcement/ (which was a big reason I chose to use it)

XMIT, yeah, I've made a little bit of progress, but not enough to really write about yet. My brain needs a small holiday break from algorithms and then I'll probably dive right back in

Also, if anyone is ever curious about building a similar machine themselves. Please PM me. It's rather expensive and very involved. But I'd love to have someone try and reproduce my results.

ohaimark
Kingpin
I'm no webdev either... So I'd stick with images and a spreadsheet. If someone else wants to work with HaaTa to get the graphs up in a different format, it's cool.

sethbc
HaaTA - this is absolutely awesome. Amazing work.

002
Topre Enthusiast
Nice one, dude!
It's fun to read through the history. I remember bits and pieces as you were moving along with this project and to see where you finally ended up is very impressive to say the least, but not at all surprising

asdfoster
Fantastic article! Super interesting. I have a quick pedantic point to make.
Actuation Force
The term Actuation Force is often incorrectly used for Force at Actuation (63 gf below). As Actuation Force really means how much force did it require in order to activate the switch (gfmm). So, just like Total Force we take the area under the force curve, but from 0 mm to actuation point (5.6 mm below).
Actually, what you calculated is the work required to reach actuation, or the Actuation Energy. The Actuation Force should indeed refer to the Force at Actuation.

You are, however, correct in saying that it is the Actuation Energy that is more important than the Actuation Force. The Actuation Energy is how much effort must be expended for each keypress; it is a good metric for how a keyboard feels and how quickly your fingers will get tired.

pr0ximity
HaaTa wrote: Yeah, if we can somehow link mediawiki to plotly, then when new analytics are ready the graphs can auto-update. I'm no webdev so I'm not sure how hard that'd be. But yeah, if something I can do makes it easier to add into the DT wiki, I'm totally up for it (as long as it can be automated ).

License wise, I only have one rule: Please link back to the original content (in this case, the plotly graph) so others can find more of the graphs. Otherwise please share/modify/extrapolate
Looks like if you couple the Mediawiki Widgets extension with Plotly's willingness to allow iframes it should be quite easy to create a Plotly widget

https://www.mediawiki.org/wiki/Extension:Widgets

Code: Select all

``<iframe width="900" height="800" frameborder="0" scrolling="no" src="//plot.ly/~haata/260.embed"></iframe>``
(from clicking the "Embed </>" modal under the graph) Looks like they also provide a public script you can link as well

Code: Select all

``````<div>
<a href="https://plot.ly/~haata/260/" target="_blank" title="Cherry 01APBSW" style="display: block; text-align: center;"><img src="https://plot.ly/~haata/260.png" alt="Cherry 01APBSW" style="max-width: 100%;width: 1618px;"  width="1618" onerror="this.onerror=null;this.src='https://plot.ly/404.png';" /></a>
<script data-plotly="haata:260"  src="https://plot.ly/embed.js" async></script>
</div>``````

drevyek
Great post. Having numbers and force curves is really important. The subjectivity of describing switches always got to me. Initially, before stating to read the post had thought that you were going to define a vocabulary to use, to absolutely define some of the words commonly used to describe switchfeel (scratchy, smooth, rough, sharp, firm, soft, etc).

Instead, this is better. This gives actual hard values to plot terms against. A "steep" ramp could be defined in terms of a slope, gF/mm; scratchiness in terms of standard deviation from a base slope, etc.

Once we have a defined vocabulary, then we can have a discussion. I'd also love to see things such as an audio analysis of switches be done. I would, but I have no audio equipment, and certainly nothing that can accurately represent these. Do Fourier Analyses on the audio samples can define terms like "high pitched", "loud", etc. I had attempted to do as such a few months ago with my Model F vs my Model M, using Praat (a linguistics tool for determining phonetic variables in speech), but my microphone was too poor to produce reliable data. I wanted to know what "deeper" meant, in real terms.

Khers
asdfoster wrote: Fantastic article! Super interesting. I have a quick pedantic point to make.
Actuation Force
The term Actuation Force is often incorrectly used for Force at Actuation (63 gf below). As Actuation Force really means how much force did it require in order to activate the switch (gfmm). So, just like Total Force we take the area under the force curve, but from 0 mm to actuation point (5.6 mm below).
Actually, what you calculated is the work required to reach actuation, or the Actuation Energy. The Actuation Force should indeed refer to the Force at Actuation.

You are, however, correct in saying that it is the Actuation Energy that is more important than the Actuation Force. The Actuation Energy is how much effort must be expended for each keypress; it is a good metric for how a keyboard feels and how quickly your fingers will get tired.
I agree 100% with this; very impressive work HaaTa, but when you are talking about work and energy in terms of force it makes for unnecessary confusion. Other than that, I can rally see this becoming an important intrument in the community - finally an end to unscientific fluff when describing switches.

bhtooefr
Fantastic work, force graphs are a resource we've sorely needed for characterizing switches.

Great effort, and great read, totally hats off!

As someone who does controlled lab experiments on human subjects, I do think precisely quantifying the input (the switches in this case) is really important. However, human's senses are still far too refined and multidimensional than machine measurements in most cases. Just to give a simple example: the machine measures direct force into the switch, but the wobbling lateral movements of a switch which also affect our key press experience are not accounted for.

Your force curves are some of the most advanced, I've seen so far. I just have one further question for you:
How does 'scratchiness' or 'rough' translate on the force curve? Does that translate to those little fluctuations along the Y-axis?

There is definitely some real difference in lubed versus non-lubed switches. It is perhaps also a good exercise to see how that translate onto the force curve, just to test how sensitive the current setup for the Keyboard Force Curve Gauge is.

HaaTa
Master Kiibohd Hunter
(responding to a few people with this)
Work vs. Total Force

Yeah, the Total Force is something that I'm still iffy on. I don't like calling it energy, because I don't feel it's representative enough for force curves.

To quote my response to the reddit thread (https://www.reddit.com/r/MechanicalKeyb ... l/da8g2oj/ https://www.reddit.com/r/MechanicalKeyb ... echanical/)
Yeah, this is something I've tossed around between. And I'm still a bit iffy on.

Yes, you are correct. We are measuring work here.

However, we have two varying quantities. Force and distance. And I wanted some way of describing the energy, but differentiate it from standard work.
So, the way I read gfmm is, "the total instantaneous force over the specified disance".

So in the case of Cherry MX Brown (https://plot.ly/~haata/86). Total Force is would be more accurately written as Total Force (across 4mm): 166 gfmm.

I haven't really gone into it in the article, but the total distance is also very important when it comes to physiological work of your fingers. And the ability of your fingers to change directions (willfully or unwillfully).

But yeah, I think the terminology could use some work. Any thoughts?
gfmm is still useful when comparing switches of different travel lengths, but it's not an apples to apples comparison. I really want people to think gfmm instead of W when thinking about switches. I want a terminology that's accessible and relatable so it's easier to explain to people less familiar with keyboards. But at the same time, correct.

Anyways, I'm very open to updating the article terminology to something that makes more sense.

Wobbliness

Menuhin, yeah, I totally agree. Human senses are crazy. Trying to approximate them is ridiculously hard. The only thing we can do is try harder
Wobbliness (or even off-center presses) is something I have thought about. At least to start, I want a solid sampling of all sorts of keyswitches pressed in the best possible conditions. The other problem is that some switches are supposed to be wobbly. Accountant calculators come to mind. On some Canon you can easily press the keys from all sorts of angles, and get reliable keypresses each time.

However, I think (with a bunch of effort) there should be a way to quantity switch wobble.

Lately, I've been thinking about wobble not just in X (left/right) and Y (forward/back) directions but also Z (up/down). Z is, an effect of the switch preload. For most cases, the higher the preload, the less likely you'll accidentally press the key. It's not just as simple as using a longer spring, because that can change the rest of the force curve as well, so it gets a bit complicated.

Scratchiness

This is probably #2 on my list for things I want to tackle next with force curves. (#1, I'm not comfortable enough yet the terminology to unveil). As you can see with an MX Green, the force gauge is sensitive enough to measure the click slider bouncing around (the oscillations) inside the switch.

What I'm curious to figure out is whether those small bumps are actually friction. If you enable the 2nd press (click on the link, and click on the grayed out legends). The bumps do seem repeatable. Each test is done at the exact same speed. My guess is that varying the speed slightly, would change the behaviour of the friction. At slower speeds, it would increase, and higher speeds it would decrease. Though oscillations would probably stay mostly the same.

Also, something I've noticed, is that the presence of the small bumps doesn't necessarily mean the switch feels rough.

This is a graph of an Alps Magnetic Reed switch. It's, by far, my favourite linear switch. Incredibly smooth. Yet we still see the small bumps.
My suspicion is that these aren't from the slider, but from the spring itself shifting around as it's pressed.

But yep, lot's of mysteries yet to be solved
Last edited by HaaTa on 21 Nov 2016, 01:26, edited 1 time in total.

drevyek
What does a known scratchy switch look like? as in, what can we used as a baseline for defining a scratchy switch?

webwit
Wild Duck
Maybe it is in the nature of spring theory. Like, a spring as a whole can be linear, but between the coils, there's a maximum distance and a minimum distance between coils when you press it down. Or maybe it's like running into a wall, and then keep trying to run (but with less force because no speed force vector) while you're already stuck (painfully) to the wall. Where the wall is a finger and the running man the resistance of the spring, trying to move up again. Or maybe it's all within the inaccuracies of your measuring equipment.

Or maybe I'm talking out of my ass.

bhtooefr
As I've said in IRC, it'd be interesting to see force versus speed for some switches like Fujitsu Peerless.

An idea I just had for it is to do the force sensing not using a load cell, but rather using current sensing on a servo. So, the servo can depress the key and keep track of its precise position in the stroke, and current sensing can tell you how much torque that servo is exerting on the key. Current draw will be affected by rate, but you can have a baseline setup that just measures rate effects on current draw, and can then be used to correct the actual force graph.

tentator
oh man HaaTA, this post is sooo great! thanks!!

fohat
Elder Messenger
webwit wrote:
Or maybe I'm talking out of my ass.
A duck only has a cloaca, no ass.

ohaimark
Kingpin
That escalated quickly. Or, rather, descended.

morkl
HaaTa wrote: Unfortunately, it’s not always easy to measure the actuation point on switches. Contact switches are straightforward. However capacitive and magnetic switches tend to be a lot trickier to get the precise actuation point. If you’re reading a graph and it’s missing the Actuation Force, it generally means that recording the actuation point wasn’t easy to do.
Have you considered using the output from the keyboard controller? I imagine an MCU with a bunch of inputs and selectable protocols, and binary one pin output (any key pressed=1, no keys pressed=0). Or just a bunch of separate controllers if selecting input protocols in runtime is too difficult.

It would add a slight delay compared to simple continuity testing, and would make the measurements somewhat keyboard-dependent. Then again, some switch types (especially the non-contact ones) have keyboard/calibration-dependent actuation points anyway...

Binge
Haata this is beautiful work. I can't wait to see this process you have expanded upon and it's impact to the community and infinity.club projects!

lot_lizard
Easily one of my favorite threads ever. Can't wait to see the intellectual capital that comes out of it. Thanks for taking this on. We needed it

Wodan