Replacing the controller on a Fukka board

[clee]

I haven't gotten my hands on an ABS M1 or a Filco Zero yet (I posted a classified, so if you want to unload yours, please let me know), but the consensus I've seen on the boards here has been that the Fukka keyswitches are great; if only the controllers had a higher scan-rate...

Well, I've implemented two logic boards for the Model M now, based on two completely different microcontrollers, so I feel like this is something I could take a crack at. I'll update this post with my status as the project progresses.

[clee]

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.

[wellington1869]

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.

[clee]

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.

Do you still have your Filco Zero or your ABS M1? I'm not picky, I'll take whichever one I can get my hands on first/easiest. And my average typing speed is roughly 120-125wpm; I definitely ran into the annoying transposition errors with the Das Keyboard III, before their latest update which I hear doesn't have that issue anymore.

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.

[sixty]

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.

[clee]

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.

Don't be so hard on yourself

If you have some basic understanding of programming, here's a great article on the subject.

The short version is, when you're programming one of these things from an embedded microcontroller, when a key is in the default (unpressed) state, it will always read (say) 0. When the key is pressed, it changes the state to 1. However, when keys are pressed, a lot of switches take a few milliseconds to "settle" and in the interim period, they will flutter between 0 and 1. Debouncing is simply the art of waiting for that settling to finish before emitting the USB HID packet that says the key has been pressed. There are a number of ways to approach it from a programming perspective, which the article I linked above (and the comments replying to it) enumerate, if you're really curious.

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.

As for "why hasn't everyone moved to the AIKON design or something as awesome" - the AIKON is unusable for commercial keyboard manufacturers because it's based on the ATmega32. Now, don't get me wrong! The ATmega32 is an AWESOME microcontroller - it's what I used for my first Model M USB controller - and the V-USB stack works shockingly well. The problem is, V-USB doesn't implement some important features like USB suspend (leaving it up to you to add code for it, if you care about properly suspending your device) and it can't support things like proper USB error checking (because of timing constraints). The AIKON is definitely slick, and I wish I had a bunch of them, but it's not a usable solution for anybody who wants to advertise USB compatibility on a product they sell and not get sued.

I'm not aware of any AIKON-like projects that are implemented using a microcontroller that properly supports USB, shipping with commercial-friendly firmware that any company could take and integrate into their shipping product. And it doesn't really make a lot of sense for any individual company to spend time or money developing such a thing since - if it succeeded - it would be like handing your enemies the best weapons you've developed for yourself and inviting them to come invade your space.

[Findecanor]

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.

Another good article by the same author is The Secret Life of Switches.
He has measures the bouncing characteristics of different types of switches (not keyboard switches... but homebrew keyboards have been constructed with some of these).
He found that different types of switches bounce at different lengths before they settle into one or the other state.
In our context, I suppose that a keyboard controller tuned for one switch could be too fast for another switch, emitting bounce.

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.

[wellington1869]

Do you still have your Filco Zero or your ABS M1?

sadly no, i sold everything and currently only use a rubber dome MS (i know, i know) and a das 3 (post-fix).

And my average typing speed is roughly 120-125wpm; I definitely ran into the annoying transposition

glad to add your testimony to the pile

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.

interesting info on the ATmega32 and USB. Also thanks for the debouncing discussion link.

[suka]

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.

For my custom keyboard project I ordered a Teensy 2.0++ just to try out and am reallly happy with it.  Afaik using the LUFA lib it really behaves as a compliant USB device with supend and all.
Lots of examples on their site or on arduino projects or avr related sites in general help to get started, and if you know how to code already it is fairly easy to use.

I struggled with debouncing too, at first, but finally got it solved when I stumbled across the great humblehacker firmware of dmw from this forum which lets you built your own configurable kb really easy.

But hacking that controller really rocks: I already have analog controls mapped to a integrated mouse device on my board, and can also hook up PS/2 keyboard or a trackball while still having enough pins available for SD-Card, LEDs, a LCD and what-not...

So give it a try, there's also other debug kits for around 20€ from other places that work as well.

[clee]

Reading that article on switch bounce and his tests it's pretty easy to see why Simplified ALPS could have a problem here.



A and B are leaf switches.

Show Image

It's good to see actual data with real numbers attached.

Even so! The leaf switches take, at worst, 6-7 milliseconds (on the graph, 6000-7000 microseconds) to settle when the switch is closed, which is when the key is pressed down if I understand correctly. Let's say the Fukkas are twice that bad, and they take up to 15ms to settle when you press the key down. (I have absolutely no data to support this hypothesis, since I still have no M1 or Zero, so I'm just thinking out loud here.)

That theoretical 15ms time-to-settle has nothing to do with how long the controller should wait between full-matrix scans. In fact, the more frequently you scan, the lower the latency between your debounce beginning and finishing, and the better the odds are that you'll properly queue up the multiple key debounces that you want. For example, if the user rolls through an 'i' and an 'n' in quick succession, if you're only scanning once every 20ms you might very well pick those keys up in scan order instead of in the order the user typed them; if you're scanning once every 1ms, you can start debouncing whichever letter came in first as soon as it shows up, and then several scans later, you can start debouncing the second one. As long as the debouncing is processed first-in/first-out, you win!

And I plan on using a Cortex M3 running at 72MHz (maybe faster, I'm not sure yet), so scanning at a rate of 1KHz or better is... well, that's a really low bar to hit. Hell, the PIC18 I'm using on this Model M scans the entire matrix at over 8KHz, which is already ridiculous overkill. I'm looking forward to finding a Zero.

[dfj]

... 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

[dfj]

The Fukka is spec'ed at 5ms.

from the ALPS wiki

A lot of keyswitches (no cite ) are spec'd at 5, though - whether they actually settle after 5, later or sooner is the more exciting question.

I'd be hoping for sooner, of course.

dfj

[clee]

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.

You are entirely correct. Almost every solution to a technical problem involves tradeoffs; in this case, I'm more than willing to trade a fixed (made-up theoretical maximum of around 15ms) latency window for zero transposed keys, at the cost of realtime responsiveness for gaming. However, while I don't doubt that you are correct that a 15ms lag could have an effect on gameplay (it certainly does when I'm playing Guitar Hero and Rock Band!), there are a few things to consider.

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.

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

I don't have my own oscilloscope yet - I spend a lot of time at a buddy's house since he's got a really nice one that I borrow from time to time.

It looks like I've finally found a source for both an M1 and a Zero. After they get here, I'll probably pick up a scope as well, since I'm going to have hardware to hack again. And, yes, I realize that the made-up 15ms number is pessimistic; hopefully very unrealistically so.

The Fukka is spec'ed at 5ms.

And I'm hoping this turns out to be true.

[Findecanor]

A lot of keyswitches (no cite ) 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.

How long can a bounce be? How does a Cherry or Alps bounce curve look like?
My assumption is that a typical switch bounces a lot first, then less and less until it settles.

Perhaps none of Ganssle's debouncing algorithms would be suitable for low-latency keyboard controllers.
Instead of waiting for the switch to settle into n identical readings out of n consecutive samples, perhaps we should instead look for >n-m number of identical samples, where m <= n/2.
As long as we get between m and n-m positive readings, then we won't notice a change of the switch's state.

If my assumption is correct and we use this algorithm, then we may not have to debounce for too long, even if the switch would take longer time.

[dfj]

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.

I agree that reaction time is not so important, as most folks have some significant lag before they react. One trouble is the the sources of variable latency within the system - this will cause folks to miss, both when shooting, and when moving, executing tricky jumps, etc...

  Another significant problem is that the longer you make the debounce detection (and this stacks with the hysteresis of the switch), the longer the minimum distance someone will be able to hold down a key for, by tapping. This is quite important when edging towards a ledge or trying to aim with a keyboard-controlled interface.

But - see what works, and good luck.
Not telling you what code to write, just reminding you of them gamer folks. I have my own controllers to worry about, after all.
dfj

  PS: fer rip: longer latencies when playing shooters results in more inconsistencies between where the client predicts the player to be, and where they actually are - resulting in missed shots, popping, etc... Your kids can likely feel the difference, even if they are not naming the problem it causes correctly.

[zefrer]

Next time my kid starts whining about his ping dipping below 20ms in TF2 I'm gonna show him this study.

Ping affects gameplay, not just response time.

You have to compensate for your ping in regards to shooting a moving target for example. This has nothing to do with human response time.