Like I said, I've done this twice before :)
I know how to write a debouncing algorithm. It's not rocket surgery.
Only way to find out is to try it, though! Still having trouble finding someone willing to sell me theirs.
clee, I'd love to see the results. Hope you find a donor board.
there was a looooooong thread on this very topic a while ago (ie, on the prospects of manually fixing scan rates on controller boards). After a long-ass discussion, many ideas, a few volunteers.... it went nowhere. I hope you have better luck though. Sounds like you know what you're doing.
In all seriousness if you're successful I would seriously consider buying the result off you.
Like I said, I've done this twice before :)
I know how to write a debouncing algorithm. It's not rocket surgery.
Only way to find out is to try it, though! Still having trouble finding someone willing to sell me theirs.
If it is not rocket science, could you please try to explain the basics of how an algorithm like this would work? When this idea of fixing the Fukkas like this was first brought up months ago it was noted by some people that you could run into problems when "recycling" a controller from another board. Now there is this awesome controller made by some Korean keyboard gods called "AIKON" (if you use the search you might find some more info on it). This controller works with pretty much every PCB design, every type of switch, n-key rollover, no n-key rollover and every other possible setup straight "out of the box". How is this possible and why do other controllers not support all of this and run into trouble with key bounce?
I am a complete dummy when it comes electronics on a microcontroller level, so I have no idea how to even start imagining a debouncing algorithm.. maybe you can shed some light.
The important thing here is that if you're doing it right, you can keep multiple key debounces in flight at once, ordered by which one came in first, so that even if the switches take an abnormally long time to settle, you can still properly preserve the order of the keys that were pressed.I think that would matter only when the difference is smaller than the USB poll interval when the 6-KRO limit is reached... Still, I am interested in seeing your algorithm.
Do you still have your Filco Zero or your ABS M1?
And my average typing speed is roughly 120-125wpm; I definitely ran into the annoying transposition
If I can find one of these keyboards (it's infuriating how I missed out on the $20 M1 deals at Newegg), and assuming that I manage to work out a decent logic board that solves the issue for me, there's no guarantee it'll work perfectly for everybody else. I have no experience mass-manufacturing anything, and even if I can get something working perfectly on one keyboard for myself, that doesn't mean it'll work perfectly on every single one. That said, I can't wait to tackle it.
I have also become interested in programming keyboard controllers... I have not started yet, and am still in the state of gathering information to see if it would be worthwhile to do on my own.
Reading that article on switch bounce and his tests (http://www.eetimes.com/discussion/break-point/4024944/The-secret-life-of-switches)it's pretty easy to see why Simplified ALPS could have a problem here.
A and B are leaf switches.Show Image(http://www.ganssle.com/images/debouncetimes.jpg)
The Fukka is spec'ed at 5ms.
from the ALPS wiki
Some games (and people)... require/want to generate sub-16ms events.
(Virtua Fighter II requires sub 16ms presses)
clee, et al.
If you debounce for 15ms, you also add an extra video frame of latency to games.
When you are debouncing a keyswitch to figure out where it is now, you have a hard problem when dealing with switches that can generate over 5ms of bounce.
In particular - a key that is now appearing off after 4 ms... is it bouncing, or has it just been released after a tap? I don't have a simple solution for you - a key that was up, then transitions down for 4ms, then up, and away - will be hard to deal with. If you detect the release, and send it, but the key stays down after, then a bad release was sent. Alternately, you could wait longer - but that is adding latency to certain gamers.
You (clee) are describing intending to buffer the events by their initial time of change detection, but only sending the events after they have stabilized. This is tricky, as it requires adding latency to all keystrokes. If you don't add the latency to all keystrokes, then gamers will randomly miss when making passing shots. When all the latencies are stable, then the brain can still sync with it.
reminders:
25 keys per second is 40 ms - gamers can do this when rapid firing.
faster typists can be hitting 15 kps, or 60ish ms.
minimum screen latency at 60 hz is about 16ms.
Flatscreen display tech will add 4-10ms to this, typically.
Also, the debouncing article (http://www.ganssle.com/debouncing.htm) does not discuss the attributes of the keyswitches we have - have you had a chance to run a few keys (clearly not fukkas, yet) through a scope? A digital scope, sound-card trace, or a long set of analog samples from an IC might do sufficiently well to see what is happening.
I think the debouncing code needs to be tuned to the capabilities of each type of keyswitch, at least. Then, if the user is trying to run at the edge of the keyboards' ability, (trying to generate very short presses on a bouncy keyswitch) an advanced feature might be to adjust the debounce time to generate faster release detection, at the cost of the occasional false release and stroke.
I guess the main thing I'm saying is that assuming that the fukkas need 15 ms to debounce is overly pessimistic, and brings one into conflict with gamer-sensitive latencies for certain situations.
I'm not going to argue with 5-7ms if the switch is an utter pain to work with, though. That level of latency will allow some of the taps one attempts to land within the same video frame, if one is attempting such a unreasonable feat. :)
I'm in 'measure stuff' mode lately, so hopefully I'll be able to post some traces of strokes from some key switches I have handy - though I don't have that decent a collection, it is crazy swung towards IBM.
yup,
dfj
The Fukka is spec'ed at 5ms.
A lot of keyswitches (no cite :P ) are spec'd at 5, though - whether they actually settle after 5, later or sooner is the more exciting question. :)You should not expect two switches to debounce for exactly the same duration in each and every circumstance.
http://hypertextbook.com/facts/2006/reactiontime.shtml says that the fastest reaction time in a test group for a human was 0.0553 seconds (or, 55.3 milliseconds), and that result was a major outlier. The average results in all of the groups were in the 150-225ms range. So I'm less inclined to worry about this issue, but I do recognize that it's definitely a potential problem.
Next time my kid starts whining about his ping dipping below 20ms in TF2 I'm gonna show him this study.