Keyboard bricks, instant matrix scan and other clacky things

User avatar
ifohancroft

31 Mar 2021, 17:01

Basically I wanted to make a post mentioning project's I'm currently working on that are related to do with keyboards, as I don't have enough yet on any of those projects to make a separate post just for it.

Also, someone might have ideas regarding what I'm working on and we can brainstorm or someone might actually be working on what I am working on and we can exchange ideas or collaborate and stuff.

1. An ErgoDox (nothing fancy here, just started making my own some time ago as a way to relearn electronics). I'm making the PCB, case and plate. It would be a standard fixed ErgoDox layout with either dual USB-C on each half or USB-C and 1/4" TRRS as I love guitar cables. Anodized aluminum case in gunmetal gray with bottom mount plate. The PCB will be suspended from the plate (won't be connected to it or the case, it would just use the solder joints on the switch legs), the USB connectors would be on a separate daughter board that would be mounted to the chassis with the chassis being grounded.

2. Keyboard bricks. I know about the DK6 Ergo keyboard project but it's expensive as fuck and from what I know it's not open source and I want to try a couple of split ergo keyboard layouts without having to build each one separately so here's my idea:

Single switch PCBs with right angle magnetic pogo pins and hotswap socket with a 3D printed enclosure (the enclosure design isn't ready as I am still considering how to make it so you can easily put/remove the PCB from it but still being able to have the switch snap-in and being able to replace keycaps without the switch coming out) so you can snap switches together forming the rows and columns with a similar way to connect to the MCU pins.

3. Instant matrix scan

Since setting pins low or high is done with binary arithmetic anyway, in theory, a single operation can be used to use send electricity to all columns at once, instead of sending it one column at a time, then checking switch per switch if it has been pressed. Admittedly, I don't know if reading the state can be done all at once.

Not there is a particularly pressing reason to do that, but it's a professional deformation for me to try and optimize the shit out of things + I like playing around with stuff.

In theory, this would keep the timings tight(er?) and predictable, at least more so than scanning a column at a time. The total time saved probably won't be much (as in probably won't even be a significant fraction of a single millisecond), but if someone wants to get into making their keyboard 8KHz it may be beneficial, specially if you add more things to the overall loop like either a split second half or macros or RGB LED lights.

P.S.

I really need to come up with a way to test various ideas. Not only thins one but generally to have a setup for an easy way to play with electronics and test various ideas without having to build what's not necessary and isolate only what I care about testing.

gipetto

31 Mar 2021, 17:23

the lain by hsgw had instant matrix scan. nkey rollover with no diodes, was a neat design.

https://5z6p.com/products/lain/

User avatar
Muirium
µ

31 Mar 2021, 17:33

Any idea how they did it?

From what I gather: a matrix is all about saving pins. Do we just have more pins available now? Or are you talking about multiplexing?

Clearly I don’t get what you’re suggesting here.

User avatar
ifohancroft

31 Mar 2021, 17:46

gipetto wrote:
31 Mar 2021, 17:23
the lain by hsgw had instant matrix scan. nkey rollover with no diodes, was a neat design.

https://5z6p.com/products/lain/
@gipetto Thank you! I had no idea it's been done already, although that's precisely why I knew it's a good idea to post what I'm working on, here even if the projects aren't far enough in.

Do you happen to know if that board's pcb is open source hardware?
Also, I can't find the board's firmware in QMK's repo either. Which is weird as the board clearly states it uses QMK.

Btw I'm sorry if this is not the case but I checked the keyboard's IC post and it doesn't mention anything about instant matrix scan. Are you perhaps mistaking no matrix/direct connection to each switch as an instant matrix scan?

P.S. I often see boards that have some great features that I haven't seen much elsewhere that are unfortunately not open source hardware
Muirium wrote:
31 Mar 2021, 17:33
Any idea how they did it?

From what I gather: a matrix is all about saving pins. Do we just have more pins available now? Or are you talking about multiplexing?

Clearly I don’t get what you’re suggesting here.
@Muirium I've always wondered how NKRO without diodes is achieved. I mean even on old keyboards (I may be misremembering the switches/keyboards that have/had NKRO without diodes and whether it was Topre or old IBMs (perhaps buckling spring?)) you still have two pads that get bridged.

In the case with the Lain keyboard I now see that it uses direct connection for each switch, hence the lack of diodes.

I tried to learn multiplexing/charlieplexing but I can't wrap my head around it. I mean with a key matrix even though I often forget where to put the diodes and how to connect the diode to the row or column I know how a key matrix works and how to create one, where with multi/charlieplexing I can't figure out how to create my own and which connections can be combined and what are the rules for that.

P.S. Was your matrix question towards gipetto or towards me?

Findecanor

31 Mar 2021, 20:13

If I recall correctly, you can't get NKRO with charlieplexing.

To read the matrix all at once, maybe you could put a different resistor on each column (each twice as the one before) and read each row using analogue-to-digital converters (ADC). However, microcontrollers tend to have only one or a few ADC units behind a multiplexer. With multiplexing and a typical ADC taking multiple cycles (one bit at a time), I'm not sure that it would necessarily be faster than a traditional matrix scan. You would also need some better better resolution (in bits) on the ADC than you have columns.
Keyboard matrices are usually strobed with a "settle time" delay between strobing and reading to get around capacitive effects. Maybe using and ADC could avoid that... but I don't know. You would need a fancy oscilloscope and probes to figure this out.

I'd think that USB is still the limiting factor anyway, even if sped up eight times.
USB is periodic: so I'd think that the way to go for lowest latency would be for the keyboard firmware to do a statistic model of when within a USB frame (one frame is every ms) that the host usually polls, and scan the matrix only just before that.

Cherry's RealKey™ tech in the MX-Board 6.0 was described as being a combination of analogue and digital tech to scan keyboards faster, but I don't know if anyone figured out how it worked. I think someone did a test that showed that it wasn't actually that fast, and that a Logitech keyboard with MX Brown switches was faster.

Paul Dietz did develop a keyboard with resistors instead of diodes when at Microsoft. Not quite NKRO, but it achieved 17 keys at once. He described it at Geekhack in 2011 as using the same principle as a resistive touch screen. This tech was used in the Microsoft Sidewinder X4 gaming keyboard. The patent is valid until 2033 though.

User avatar
ifohancroft

31 Mar 2021, 20:42

Thank you very much for that info!
Findecanor wrote:
31 Mar 2021, 20:13
If I recall correctly, you can't get NKRO with charlieplexing.

Maybe you could put a different resistor on each column and read each row using analogue-to-digital converters (ADC). However, microcontrollers tend to have only one or a few ADC units behind a multiplexer. With multiplexing and a typical ADC taking multiple cycles (one bit at a time), I'm not sure that it would necessarily be faster than a traditional matrix scan.
Keyboard matrices are usually strobed with a "settle time" delay between strobing and reading to get around capacitive effects. Maybe using and ADC could avoid that... but I don't know. You would need a fancy oscilloscope and probes to figure this out.
I am not necessarily trying to use multiplexing or charlieplexing with keyboards, specially I am not trying to achieve what I mentioned about instant scanning with them. I just saw it mentioned and decided to comment that I have generally struggled to understand it. However, what you mentioned is interesting, so thank you!

Speaking of using resistors instead of diodes - according to what you said, I guess it's possible, but even if we imagine it's possible without the added complications and we can just use resistors as a drop-in replacement for diodes, there's not much sense in doing that. I am perfectly fine with using diodes for avoiding ghosting. I'm just curious how the keyboards that have done it without diodes and any other workaround (from what I remember there are such, although not with MX style switches, but I can't provide any sources right now or remember specific boards) and if possible to be done on any keyboard, I'd like to do it because why not.

Findecanor wrote:
31 Mar 2021, 20:13
I'd think that USB is still the limiting factor anyway, even if sped up eight times.
USB is periodic: so I'd think that the way to go for lowest latency would be for the keyboard firmware to do a statistic model of when within a USB frame (one frame is every ms) that the host usually polls, and scan the matrix only just before that.
On High-Speed USB (I believe High-Speed was faster than Full-Speed, the names are confusing) one microframe is 125 microseconds (1/8th of a millisecond) so you can get polled/send information 8000 times per second with USB.

Findecanor wrote:
31 Mar 2021, 20:13
Cherry's RealKey™ tech in the MX-Board 6.0 was described as being a combination of analogue and digital tech to scan keyboards faster, but I don't know if anyone figured out how it worked. I think someone did a test that showed that it wasn't actually that fast, and that a Logitech keyboard with MX Brown switches was faster.

Paul Dietz did develop a keyboard with resistors instead of diodes when at Microsoft. Not quite NKRO, but it achieved 17 keys at once. He described it at Geekhack in 2011 as using the same principle as a resistive touch screen. This tech was used in the Microsoft Sidewinder X4 gaming keyboard. The patent is valid until 2033 though.
Thanks! I'll checkout those!

Yeah, synchronizing the poll with the scan will definitely help speeding things up.

I believe that's done by default in most high-end wired mice. I don't know if it's done with wireless mice as there you have to sync not only the scan with the poll but also the communication between the MCU and the sensor and as far as I can remember one part of the chain is synced there but not the other, but I can't remember which.

Whether doing an instant scan will help much with the sync, I doubt it as I believe it can be synced either way and even without an instant poll you probably can still get the scan time to be consistent every time, but syncing the scanning with the polling + doing an instant scan I believe would help if sending data/getting polled every 125 microseconds.

Not that there really is a point of that but it would be fun for me to play around with it. I also need to take a better look at QMK's code to see how certain things are done and see if I can optimize them.

User avatar
Muirium
µ

31 Mar 2021, 21:26

ifohancroft wrote:
31 Mar 2021, 17:46
…whether it was Topre or old IBMs (perhaps buckling spring?)) you still have two pads that get bridged.
Capsense. Topre, Model F and indeed Beamspring are all NKRO without any diodes. But none of them bridge the pads. They move a conductor near the pads, altering the capacitance, but never actually touch them. (The pads are on the PCB and are in fact covered with an insulating mask.) So ghosting and blocking on the matrix doesn’t happen. Not the obvious way at least.

As for exactly how all these capacitance values are probed: I’m guessing it’s a tuned circuit, or a resistor and a timer, or something analog like that. You’re just making a capacitance measurement. You’d think probing a whole row of pads and a whole column at once would be messy, but capsense is pretty good at keeping the signal to noise ratio perfectly high for reliable sensing. Especially when you have a different threshold allowed per key. :D

User avatar
ifohancroft

31 Mar 2021, 23:11

Muirium wrote:
31 Mar 2021, 21:26
ifohancroft wrote:
31 Mar 2021, 17:46
…whether it was Topre or old IBMs (perhaps buckling spring?)) you still have two pads that get bridged.
Capsense. Topre, Model F and indeed Beamspring are all NKRO without any diodes. But none of them bridge the pads. They move a conductor near the pads, altering the capacitance, but never actually touch them. (The pads are on the PCB and are in fact covered with an insulating mask.) So ghosting and blocking on the matrix doesn’t happen. Not the obvious way at least.

As for exactly how all these capacitance values are probed: I’m guessing it’s a tuned circuit, or a resistor and a timer, or something analog like that. You’re just making a capacitance measurement. You’d think probing a whole row of pads and a whole column at once would be messy, but capsense is pretty good at keeping the signal to noise ratio perfectly high for reliable sensing. Especially when you have a different threshold allowed per key. :D
Thank you! I guess I was confused that they short the pads because of how a Topre and Model F PCBs look and misremembering what I heard in a video.

HuBandiT

09 Apr 2021, 02:47

There are enough pins today to have each switch wired directly to an individual pin. And then you choose a microcontroller that has notification on pin change (or write that in FPGA), and aside from NKRO that would trivially give you things like a 200 MHz (or whatever clock speed you are running) polling rate with the same time resolution for debouncing, plus zero keypress debounce latency: since you know the switch was unpressed for a while, and the switch won't spontaneously close the contacts, the very first contact indicates the key was pressed... you can report the keypress instantly to the host computer (and gamers will love you for this and pay you lots of money – USB2.0 has an 8 kHz polling rate theoretically, you could be one of the few devices actually utilizing this), and then you have ample time resolution to clearly watch the bounce unfold in very slow motion (200 MHz clock vs. 5 ms bounce gives you a million clock cycles per bounce), and be able to clearly tell it apart from a repeated keypress. And it would also give you crazy things like infer – to some degree – how fast (with what force) a key was pressed from the change in bounce patterns (think how different the timing of dropping a ball from 6 inches vs 5 feet is) – giving you a velocity-sensitive musical keyboard based on vanilla Cherry MX switches. (Or you know, some useful things; like correctly recognizing 'E' 'R' when someone types quickly and rolls these two – instead of randomly changing it to 'R' 'E' when the user caught two of your scanning cycles at just the wrong moment.)

(Heck, you could probably wire up all switches in parallel to just one pin, and then recognize them just by their bounce. Granted it would only be 1KRO, but how cool would it be?! Readers interested in following current industry trends could train a statistical model (popularly called "AI") on this to then achieve probably somewhere around 2.4-3.2KRO with a 98.6% accuracy running near real-time on commodity mid- to high-end GPU hardware.) (Oh, and did I tell you how you could increase KRO on membrane keyboards by having the microcontroller measure the resistance of the conductive ink paths connected by the keypresses?)

Plus, since you are not constantly electrically wiggling lines around, you emanate much less EMF, which is better 1) for health, 2) for power consumption (think wireless battery-operated keyboard – in which case design with much lower clock speed, plus halt the microcontroller entirely until a key is pressed), 3) against spying on what was typed. (If you are worried about the latter case though, you just put yourself in even deeper trouble, as you would now give off key timing patterns – great for identifying both what was typed, as well as who typed it – much more precisely than if you were just crudely polling at around a 50-400 Hz rate as is the norm today. On the other side of the coin though some will consider this a feature, and use it as effective biometric identification of the user – even down to the individual key press velocities, influenced by hand geometry, position and typing technique, state of intoxication, lack of coffee, etc.)

Too many ideas, too little time. Someone else please do it (and share profits with me). Or route me a PCB.

User avatar
Muirium
µ

09 Apr 2021, 10:41

Lack of coffee? Sounds like you had ALL of it to me! :lol:

The thing about bounce is that it is noise, not a signal in its own right. If you look at it with an oscilloscope it's a lot of spiky chaos.

Image Image

That's a perfectly functional Cherry MX blue switch under the scope, thanks to vvp. 200µs and 20µs timeframes. It's not even a chattery Matias!

Naturally, all we ever do is smooth that stuff out. The left pic—1/5 of a second wide!—is an obvious transition from low to high. But the right one? You could certainly try reporting a low to high transition faster, but you'd need to experiment to see what false positives that throws up across the whole keyboard.

Cherry MX is a simple contact switch. What you're really seeing is the microscopic chaos that happens when contacts close. Can you really make out key velocity from white noise like that? You could try. I don't have much faith the information you seek is actually in there, however!

Even analog switches with capacitive sensing have bounce. Take a look at Xwhatsit's beamspring stuff:

Image Image

The blue trace is the signal he's reading from the beamspring, by the way. The cleaner yellow trace is his row drive, used to scan those columns. Those two pics are simply a key unpressed on the left, and pressed on the right.

Capsense can theoretically give you information on key velocity, because unlike MX etc. it is fundamentally analog and therefore capable of actual shades of grey. But practically speaking, even that's quite a challenge when you look at the real signals, alive with noise.

HuBandiT

09 Apr 2021, 16:53

Well, until I've done my own scope traces to refute myself (and that with a non-clicky switch - that 1/5th second thing looks suspect), I choose to believe it is possible. :)

It would be nice to know the key switch circuit those scope traces above were observed on.

Also, a cycle of a 200 MHz clock is 5 nanoseconds – a thousandfold finer timescale than the 200 and 20 µs quoted and displayed above. Who knows what happens down at those fine time intervals. Perhaps what looks like noise above becomes a series of perhaps unevenly spaced indeed, but nevertheless individually delienable and identifiable micro-arcing events. On which one could perform statistics. That, or we get swamped by DMA's light dimmer again. (See his descriptions in his capsense thread on spurious interference.)

Also, he did not perform a keypress-velocity sweep. :) That would provide data for us to munch over to see whether keypress speed might be recognizable. We only see individual actuations. I accept the actuations are noisy indeed – but maybe they are noisy in a statistically consistent way. Of course each key would have it's own individual "twang" and therefore noise profile stored in the microcontroller memory, so that keys can be velocity-calibrated individually (like on better musical keyboards). :P (EDIT: Oh sorry, I see he did! Need to look at that then.)

But this is all just stuff dreams are made of.

Post Reply

Return to “Workshop”