Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: Keyboard anti-ghosting comparison

  1. #11
    rawrnomnom diluzio91's Avatar
    Join Date
    Jan 2010
    Posts
    2,471

    Default Re: Keyboard anti-ghosting comparison

    as a follow up to my thoughts about my ocz elixir, it bombed, but i still love the way it feels, so i will forgive it.
    Not dead yet

  2. #12

    Default Re: Keyboard anti-ghosting comparison

    Yes, I do work for MS as a researcher (and yes, that is my paper on the PSK). I'm not a product guy, but hopefully my stuff does eventually make it into product, as happened with the X4. I can't claim to be an expert on all aspects of keyboard design - I'm more of a multitouch guy just applying my craft in that space.

    USB vs. PS/2 is a bit of a mixed bag. USB is much faster, but the standard HID spec didn't anticipate pressing large numbers of keys simultaneously. There are workarounds to this problem, but none are ideal. PS/2 will let you press any number, but it's slower and it's simply unavailable on a lot of modern machines.

    For the PSK, we emulated a high speed COM port via USB and sent the data with a number of custom protocols. If you want this to play regular keyboard, you need to have something running that reads the COM port, and injects key events. Not particularly optimal...

    As for the controllers, you are right that these can be a limiting factor. I tend to think of this as a hierarchy of limitations:

    1) What the matrix can detect
    2) What the controller can process (i.e. debounce, etc.)
    3) What the com protocol will let you send

    Most membrane keyboards start having matrix problems at 3 keys. Now, it's not every three keys. It's something on the order of 4% of the 3-key combinations. There are larger sets that can still be detected and sent. Typically, this is where you run into processor or com limitations.

    On resistive multitouch based keyboards (the X4, and our "adaptive keyboard" which was in the news last week) and diode based keyboards, the matrix is not a limiting factor.

    BTW, before I get the question, the keyboard on the adaptive unit uses resistive multitouch, but the screen is capacitive multitouch...

    The resistors on the membrane are screen printed, just like the wires. This is what makes it so inexpensive to build an X4.

    As for speed, WPM is an average speed measurement. Peak speeds can be much higher. If multiple keys are pressed within a single scan, they can be reported in the wrong order. This is more of an issue for fast typists than gamers. Again, this is one of those things that people don't tend to notice - they presume they really did type things in the wrong order, and respond by increasing their delay between keys until it works.

    Anyhow, it always a pleasure chatting with people who understand the issues!

  3. #13
    Anodized. Again. Konrad's Avatar
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    1,060

    Default Re: Keyboard anti-ghosting comparison

    Hmmm. The material I've been absorbing tends to assume a standardized matrix layout, it emphasizes controller functions, particularly timing and debounce issues. USB development is well documented, but might be difficult (for me) only because I can't legally identify my "product" as being made by a registered vendor (I'll probably have to "steal" the identity of some other HID I never use). Documentation about PS/2 protocols seems to be museum stuff now, impossible to find, or written in Chinese.

    Your insights, how you choose to prioritize the barriers, are very interesting to me. As a one-shot project I don't suffer any of the mass-market engineering concerns (logistics chain, regulatory hassles, BOM costs, extensive product/compatibility testing, deadlines, reports) that you do, though of course I also don't have any of the advantages either (megabudget, lab and fab facilities, rapid prototyping, in-house PCB, idle engineers, secret archives).

    So the way I'm envisioning my "ultimate" keyboard plan now goes -

    0) The limits when determining physical form factor, chassis geometry, keyswitch types, keycaps and other cosmetics are ultimately based only on available budget and skill.
    1) Matrix limitations are just a matter of tradeoffs, the extreme approach to avoiding limits is simply to wire each key on an independent parallel circuit (with diodes, resistors, caps if really necessary). More work, but worth it.
    2) Controller limits shouldn't be a problem if I "overkill" with say, a pair of $8 Parallax Propellers ... each rated at 32 or 40 I/O lines, up to 80MHz (PLL), 8 cores ("cogs"), 32KB RAM, 32KB ROM (can use some ROM to store user-programmed keys/macros and settings when unpowered, keyboard can operate without imposing a software hit on the OS); spare cogs can be used to drive accessories like integrated USB hubs and programmed backlighting effects.
    Much better (and easier for me to program!) than the Holtek parts I've been looking at.
    (* Yeah, that's right - a pair of 8-core processors running the keyboard, lmao *)
    3) Unknown. I need more data to make a decision between USB and PS/2. Additional limits might be imposed if I choose a controller part which uses poorly-written libraries. Using a simulated COM port (or what the hell, even a serial COM port) is an interesting idea. At least I can see that the sort of simultaneous keyscanning I desire is possible with that method.

    I'll try not to bug you with (too many) questions - I hate spoonfeeders, but I might be "back" if/when I get seriously dead-ended.

    I might need help when trying to design some kind of "anti-tamper" logic which can detect or defeat in-line hardware keyloggers (just a random idea). I'm not paranoid, actually, but it's an interesting project and might even prove useful. Or maybe not.

    [Edit]

    Thanks, btw!
    And I happen to have been following the adaptive keyboard trail, as well. Is that you on the video? (If so, then I've seen you before, Mr Microsoft Accessibility guy)
    My mind says Technic, but my body says Duplo.

  4. #14
    Like a Lightning Bolt in Your Cheerios! Drum Thumper's Avatar
    Join Date
    Jan 2007
    Location
    Montana
    Posts
    4,522

    Default Re: Keyboard anti-ghosting comparison

    Quote Originally Posted by electron_plumber View Post
    USB vs. PS/2 is a bit of a mixed bag. USB is much faster, but the standard HID spec didn't anticipate pressing large numbers of keys simultaneously. There are workarounds to this problem, but none are ideal. PS/2 will let you press any number, but it's slower and it's simply unavailable on a lot of modern machines.
    Ok, this raises a question on my part--with the advent of 3.0, couldn't the HID be retooled to handle simultaneous keystrokes of a larger nature? Or am I comparing apples to oranges?
    Quote Originally Posted by artoodeeto View Post
    aw heck guys. We're modders. Let's just build our own, shall we?

    DrumThumper.net || The Brewing Art ||
    My Flickr Stream

  5. #15
    Anodized. Again. Konrad's Avatar
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    1,060

    Default Re: Keyboard anti-ghosting comparison

    I'm certainly not the expert here, but as I understand it

    The majority of HID keyboards (including the "1000Hz" gaming ones) on market today use USB1.x (1.5Mbps Low-Speed or 12Mbps Full-Speed) - it's all they need. I've found some that use USB2 (480Mbps High-Speed) - they all have built-in USB2 hub controllers*, and the HID (keyboard) component is treated by the USB host as a separate device/function which seems to still operate only at Low-/Full-Speed.

    The big bottleneck on "maximum speed" appears to be how fast the BIOS and OS can accept characters without choking (keyboard controller can't send a character until the host sends a ready signal, so the rate is controlled). Current USB keyboards can already exceed this rate, even without using USB2 speeds. The only "fix" I can think of is rewriting the HID libraries on the host, which might speed up the rate for the OS but can't speed up BIOS hardware. I've seen some commercial USB-developer software which appears to offer High-Speed and Super-Speed HID libraries, but maybe it's only for pointing devices (which are not enslaved by forced compatibility with ancient IBM keyboard controller chips). I could be wrong, I'm still a bit of noob in this area.

    I haven't seen any keyboards or mice with USB3 ... the immediate giveaway would be the new USB3 connectors with extra pins.

    [Edit again]
    * One keyboard, the Gigabyte GK-K8000, only integrates a USB1.1 hub controller but also integrates a C-Media AC'97 audio controller.
    My mind says Technic, but my body says Duplo.

  6. #16

    Default Re: Keyboard anti-ghosting comparison

    Quote Originally Posted by Konrad View Post
    So the way I'm envisioning my "ultimate" keyboard plan now goes -
    ...
    1) Matrix limitations are just a matter of tradeoffs, the extreme approach to avoiding limits is simply to wire each key on an independent parallel circuit (with diodes, resistors, caps if really necessary). More work, but worth it.
    2) Controller limits shouldn't be a problem if I "overkill" with say, a pair of $8 Parallax Propellers ... each rated at 32 or 40 I/O lines, up to 80MHz (PLL), 8 cores ("cogs"), 32KB RAM, 32KB ROM (can use some ROM to store user-programmed keys/macros and settings when unpowered, keyboard can operate without imposing a software hit on the OS); spare cogs can be used to drive accessories like integrated USB hubs and programmed backlighting effects.
    Much better (and easier for me to program!) than the Holtek parts I've been looking at.
    (* Yeah, that's right - a pair of 8-core processors running the keyboard, lmao *)
    3) Unknown. I need more data to make a decision between USB and PS/2. Additional limits might be imposed if I choose a controller part which uses poorly-written libraries. Using a simulated COM port (or what the hell, even a serial COM port) is an interesting idea. At least I can see that the sort of simultaneous keyscanning I desire is possible with that method.
    Just a couple of quick tips for rolling your own. First, there is no advantage to wiring each switch individually versus simply making a standard row column matrix IF you put a diode in series with each switch. If you do that, a single Propeller has more than enough I/O, and there are no blocking/ghosting issues. I highly recommend that. Compared to your other expenses (like all the individual switches and the big PCB), the diodes are cheap.

    USB is a pain, so many lazy people like myself will use the FTDI parts to convert a serial data stream to USB, giving you what looks like a virtual COM port on the PC side. You can even buy cables with the FTDI part built in! (By the way, while very handy, those work best at lower baud rates. I typically try to restrict those to 9600 baud because you start getting errors. The problem is the long cable to chip. If you mount the FTDI part next to your circuit, you can run at 1M baud, which is very nice. You might need to tweak the latency in the driver for this to work well...)

    Good luck!

  7. #17
    Anodized. Again. Konrad's Avatar
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    1,060

    Default Re: Keyboard anti-ghosting comparison

    Thanks for the tips

    I'm beginning to suspect that cable signalling latency (=lowered stable baud rates) isn't as much an issue with PS/2.

    I've decided I'll try to build a dual controller; first focus will primarily be PS/2 because that's a lot easier for me to work with right now, especially at BIOS pre-boot; USB can support higher signalling, power supply (for the keyboard) and more features ... I can add that after PS/2 working.

    One potential issue I can find no information. Power draw by the keyboard can fluctuate, actually by a fair amount when USB hubs, banks of LEDs, etc are considered. I'm uncertain if the USB host handles power automatically or if the USB device needs to explicitly ennumerate a request when changing power consumption.

    I've never actually used FTDI; usually similar MAX, SX, PIC, dsPIC, ARM parts when I need "modular" RS232 or USB interfaces. Are the baud-latency problems you describe the sort of thing I'd encounter regardless of the part, or just a real issue with FTDI?

    Yeah, one Propeller is overkill. Two would be ridiculous, I'll have to use the other one for some other project.

    Even though I originally scorned the idea, I was already favouring using a diode matrix approach before you suggested it (reduces total wiring/trace lengths by at least 75%). $6 for a bucket o' diodes isn't an issue but the 200+ solder points (hand soldering, and testing) looks a little tedious. Expenses aren't so high, really. I'll sacrifice a cheapo keyboard (complete with keys, switches, etc) to experiment on the controller/programming, then once satisfied, I'll just install it into the desired keyboard (Merc Stealth, heehee, I love the backlighting) and hammer out the details.

    Of course I'm still at the "design" stage. Haven't actually built or programmed a thing yet; my "specifications" are actually evolving as I collect information and learn what it's about.
    My mind says Technic, but my body says Duplo.

  8. #18

    Default Re: Keyboard anti-ghosting comparison

    I think the issue is with driving logic level serial at high rates over a long cable. It's not differential like USB, and the impedance is not well controlled, and I think the cap/ft is pretty high. So you want to make the USB cable the long link, not the logic level serial. I think this would be true for any system like this, regardless of part...

    I'm no expert on USB, but if memory serves, you get up to 100mA automagically, and up to 500mA if you request it. That can drive quite a few LEDs. Some keyboards add a second USB connector just so they can legitimately take twice as much power. Of course, most desktops will let you draw much more than this. Laptops are a different story...

  9. #19

    Default Re: Keyboard anti-ghosting comparison

    Oh, and one more thing. The USB standby current spec is very tight - only 500uA!

  10. #20
    Anodized. Again. Konrad's Avatar
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    1,060

    Default Re: Keyboard anti-ghosting comparison

    Ouch 500uA. I thought 100mA (or at least 50mA) was "guaranteed" service?
    Propeller can standby as low as 50uA, but that's really pushing it. Registers and RAM (including running code) flake out below 1mA unless the part is slowed to < 20Hz, plus sluggish recovery.

    Yeah, laptops suck for power output, I avoid using 'em for RS232 (pitiful voltages) and was automatically going to do the same here. Maybe USB is better regulated. Still, I doubt this (or any other) gaming keyboard will see use on a laptop, so this shouldn't be an issue unless I'm just tweaking for compatibility.
    My mind says Technic, but my body says Duplo.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •