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/c99f9a40da2ee1fd564d056a73c972cc93dd990d/fcv.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/c99f9a40da2ee1fd564d056a73c972cc93dd990d/fcv.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/c99f9a40da2ee1fd564d056a73c972cc93dd990d/fcv.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/c99f9a40da2ee1fd564d056a73c972cc93dd990d/fcv.py#L540

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