New vs worn switch characterization. - Overclock.net - An Overclocking Community

Forum Jump: 

New vs worn switch characterization.

 
Thread Tools
post #1 of 6 (permalink) Old 12-13-2016, 10:33 PM - Thread Starter
New to Overclock.net
 
TranquilTempest's Avatar
 
Join Date: Aug 2011
Posts: 1,669
Rep: 78 (Unique: 63)
Recently one of the microswitches(Omron D2FC-F-7N) on my CM Storm Spawn wore to the point where the mouse would randomly release partway through a drag(They didn't even bother hooking up the switch's NC contact to the microcontroller). So I replaced the switch, hooked it and a brand new switch up to an arduino, and gathered some data on bounce characteristics with a few hundred simulated clicks(used a piece of plastic as a mouse button).

Surprisingly, even the new switch had some really nasty behavior, with, in one instance, the normally open contact losing contact for 200ms when it should have stayed closed. 5% of the time it was over 100ms.

Less surprisingly, it seems like the new switch has a slightly stronger spring in it, so it takes a little less time to snap across the gap.


Full Results:
https://docs.google.com/spreadsheets/d/1nRi2shUTZub3mqHZXKdhgBq8NKX_2y0DgB3nOsKA3q8/pubhtml

Source code(I used an arduino micro):
http://pastebin.com/hjRk3yTE


Explanation of the various measured times:

flightDown: The time the contact takes to snap from the normally closed contact to the normally open contact when you press the button. Pressing the switch very slowly can make this number very high(several seconds/as long as you want). Flicking the switch can make this number very low(400µs).

flightUp: The time it takes the switch to snap from the normally closed contact to the normally open contact(releasing the button).

maxSingleBounceOnPress: While the switch is bouncing(within 10ms of first closed reading), this is the longest duration between a closed reading and the next closed reading of the normally open contact.

minSingleContactDuration: While the switch is bouncing(within 10ms of first closed reading), this is the shortest time between the first closed reading of the switch and the next open reading of the switch. (I need a faster setup to be confident in a value here, all I can say is you'd need more than 60khz polling rate to catch the closed portion of every bounce if you're not using interrupts).

maxSingleBounceOnRelease: Same as maxSingleBounceOnPress, except after the end of the settle time. This is still the normally open contact..

settleTime: The amount of time it takes for the NO contact to stop bouncing when the switch is pressed, (capped at 10ms, actual settle time typically about 1ms).

bounceNumber: Number of bounces during the settle time.





Caveats/future investigation: The old switch has been soldered and desoldered, the new one has not, so a change in spring characteristics could be caused by the temperature cycling instead of mechanical wear/fatigue. The switch mounting could also be an issue. I may solder both switches to some protoboard to get some more consistency there. Someone with a lot of switches might do a series comparing different brands/models/batches of microswitch.



What this means for mouse developers:

If you have double throw switches and extra pins on your microcontroller, USE THEM! If the NO contact reads closed, the button is definitely pressed. If the NC reads closed, the button is released. You don't need any delays for reliable debouncing. (the only reason to delay before reading a button closed is if you have really bad EMI problems. If you want to account for that, only enable that delay if you somehow read the NC and NO contacts both closed at the same time.) This is the only debouncing method that is both fast and reliable.

If you can only afford single throw switches of similar construction, or only use one contact to detect presses, there is no option that is both fast and reliable, you would have to find a way to ignore a 200ms bounce while still registering all the valid clicks(and I can click faster than 5hz).

TranquilTempest is offline  
Sponsored Links
Advertisement
 
post #2 of 6 (permalink) Old 12-13-2016, 11:23 PM
New to Overclock.net
 
Watery Chemical's Avatar
 
Join Date: Aug 2016
Posts: 60
Rep: 8 (Unique: 8)
Pretty sure almost every mouse company only uses 2 pins for every 3 pin switch.
Watery Chemical is offline  
post #3 of 6 (permalink) Old 12-13-2016, 11:26 PM - Thread Starter
New to Overclock.net
 
TranquilTempest's Avatar
 
Join Date: Aug 2011
Posts: 1,669
Rep: 78 (Unique: 63)
Quote:
Originally Posted by Watery Chemical View Post

Pretty sure almost every mouse company only uses 2 pins for every 3 pin switch.
Yup, and that's the main reason behind the various ways mouse clicks tend to fail(plus the main reason many mice have click latency). Also the reason I started this thread.

TranquilTempest is offline  
Sponsored Links
Advertisement
 
post #4 of 6 (permalink) Old 12-14-2016, 05:12 AM
New to Overclock.net
 
Amynue's Avatar
 
Join Date: Aug 2015
Posts: 36
Rep: 2 (Unique: 2)
Omron D2FC-F-7N (5mln) are trash, never buy mice with those, unless you are into soldering or waiting for warranty replacements.
Amynue is offline  
post #5 of 6 (permalink) Old 12-14-2016, 06:39 AM - Thread Starter
New to Overclock.net
 
TranquilTempest's Avatar
 
Join Date: Aug 2011
Posts: 1,669
Rep: 78 (Unique: 63)
Quote:
Originally Posted by Amynue View Post

Omron D2FC-F-7N (5mln) are trash, never buy mice with those, unless you are into soldering or waiting for warranty replacements.
Say someone builds an engine that can last 200k miles. A car manufacturer uses that engine in one of their cars and decides not to hook the oil pump up. Obviously such an engine is complete trash when it dies after a couple dozen miles with no oil, right?

It's not just D2FC-F-7N that has this issue either. It's likely to happen in all switches of similar design.

TranquilTempest is offline  
post #6 of 6 (permalink) Old 12-14-2016, 05:45 PM - Thread Starter
New to Overclock.net
 
TranquilTempest's Avatar
 
Join Date: Aug 2011
Posts: 1,669
Rep: 78 (Unique: 63)
Quote:
It's not just D2FC-F-7N that has this issue either. It's likely to happen in all switches of similar design.

Another example of this behavior, as tested by qsxcv with a different model of microswitch:
Quote:
so i hooked up my oscilloscope to my g303's d2f-01f left click.
take a look at this picture: http://i.imgur.com/SR5SNlo.png
note the timescale... 500ms

i was able to have the pin toggle this many times, this slowly, while the switch was physically pressed the entire time.

edit: to those unfamiliar with oscilloscopes, that's 500ms per division, the left edge to the right edge of the screen is 6 seconds.

TranquilTempest is offline  
Reply

Quick Reply
Message:
Options

Register Now

In order to be able to post messages on the Overclock.net - An Overclocking Community forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.
User Name:
If you do not want to register, fill this field only and the name will be used as user name for your post.
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself.
Email Address:

Log-in



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off