CommonSense: matrix LCR meter with a HID interface

[Techno Trousers]

62 key rollover ought to be enough!

[DMA]

tentator, good news - PSoC6 will support mbed, at least that's what they promise on early adopters' forum.
tmk_core is ported to mbed, so it's quite possible to see tmk-cored BT/USB beamsprings next year.

By next year all those oversampling and layouts-on-the-fly ideas will prove themselves fabulous/shitty and be either adopted by hasu or forgotten, so upstream will be used

Oversampling and "1 key per frame" seem fabulous now though.
T420 keyboard always outputs "gf" when you smack them together with staggered fingers (until it's just "g" or "f"), while beamspring under test can reliably tell which one drops first starting at ~2mm difference. Will hook up the scope tomorrow and see how much is that in milliseconds.

[tentator]

hehe I see, but surely I see your point and also wouldn't mind something like kiibohd, the best whish of course is being able to redefine layouts without need to reflash but still have nifty things like my beloved actions "ACTION_MODS_TAP_KEY(MOD_yyy, KC_xxx)" and "ACTION_LAYER_TAP_KEY(n, KC_xxx)" !! ))))

But you seem to proceed impressively fast! Great!

tentZZ

[DMA]

hehe I see, but surely I see your point and also wouldn't mind something like kiibohd, the best whish of course is being able to redefine layouts without need to reflash but still have nifty things like my beloved actions "ACTION_MODS_TAP_KEY(MOD_yyy, KC_xxx)" and "ACTION_LAYER_TAP_KEY(n, KC_xxx)" !! ))))

Doesn't seem hard to implement. In fact, looking at tmk_core, doesn't seem hard to move layouts to EEPROM (though at 32 bits per key one will need hell of a lot of EEPROM.. PSoC6 promises 1MB of flash and has emulated eeprom component, so down the road it's definitely feasible).
BUT. The point is to get something working for initial deployment. Firmware can be improved in the field.
If people will be fine with just layers - there will just be layers in initial release.
The situation when I can spend full week working just on this is unique and (I really hope!) short-term.

But you seem to proceed impressively fast! Great!

Well, no research on that part. Also it's a bit like being back after you spent a month in the mountains recently. When it takes huge mental effort to get out of the bed - you kind of train your mental muscle and then when that's not there - you jump instead of walking

[DMA]

So. I've added the expansion header to the project (it was laid out from the start, I just didn't have any use for it till now), and sprinkled the logic with GPIO driving commands. Here's what I discovered.

1. Things work as expected. It is still possible to press 2 keys at the same time (left key always wins in this case), but it's damn hard now.

oversampling-case.png (39.53 KiB) Viewed 9505 times

Ch2 is "scancode added to scancode buffer", Ch1 is "scancode processed, resulting keycode put to keycode buffer", Ch3 is "keyboard report updated and dispatched over USB", Ch4 is a row line to show scan pulses.

Spoiler:

Closer look. Some jitter is visible between key processing and shipping the report.

Oversampling-zoomed.png (38.56 KiB) Viewed 9505 times

That's how things look at the sensor with no noise filtering. Here and below Ch3 is a sense line.

Oversampling-trigger.png (45.35 KiB) Viewed 9505 times

Oversampling-trigger-zoom.png (43.94 KiB) Viewed 9505 times

Lightning-fast, but should you catch a noise spike at the right moment, you'll have a spurious keypress.

Now adding IIR 3/4 filter (Supposed to be "result is 3/4 of the old value and 1/4 of the new" - but implemented as "result is 3/4 of old value + new". The reason is when your input signal is less than 4 - it becomes zero when you use bit shifts to divide.)

Oversampling-IIR-trigger.png (45.54 KiB) Viewed 9505 times

Oversampling-IIR-trigger-zoom.png (43.08 KiB) Viewed 9505 times

2.5ms delay. "Wait, but that's 9 samples, not 4!" - you'll say. That's why it's called _infinite_ impulse response! Yes, I kind of expected 4. But because only readings under that dashed green line count, and the threshold (for the filtered value) is that same line. You can reduce delay by shifting threshold higher - at noise immunity's detriment.

Now for the interesting part.
Ch1 is an adjacent column now.

Oversampling-IIR-2keys.png (51.73 KiB) Viewed 9505 times

Oversampling-IIR-2keys-zoom.png (25.01 KiB) Viewed 9505 times

Sorry, no pictures with same-millisecond keypresses . Because of beam springs' nature, to get picture readable I had to hold six keys (two columns, 3 rows) and then tap two others. Since I only have two hands, I had to resort to single trigger mode on the scope and rearm it manually after every attempt. It's tiresome

[DMA]

Firmware - discovered couple of mis-routings causing right ADC part to have readings ~half of left ADC, fixed.
Problem was caused by extRef pins mapped to wrong half of the chip - it worked, but since ADC's extRef cannot be moved, input lines were routed to another half, and it looks like path resistance was asymmetrical between halves.
Also discovered that both discharge pins were routed to the right side, but that wasn't noticeable except as a strange ball of yarn in analog editor.

FlightController: Tabbed interface -> multi-window interface.
I think I need to unleash some kind of linter on it - significant changes, I may have forgot to remove some code.

Both: setup mode, in which keyboard stops sending USB codes on normal reports and starts sending scancodes over the management interface so that FlightController can highlight a key currently pressed (helps A LOT in layout editor!).

I think this is it.
I'll try to compile the utility for mac and linux tomorrow and try connecting to mac, linux and BIOS as well.
Also recompile back to F122 configuration and see how that goes.
If those tests pass - we can start voting Monday, despite lack of actual integration tests with MF.

There's one known problem - config upload and download just stops sometimes. This happened when I moved controller's management interface inbox from USB endpoint to using control channel and HID SET_REPORT.
Wanted to save some resources at USB controller side, having one less EP to poll 1000 times a second. It's not much of a problem - have yet to see a corrupted block. But may be I'll just put that EP back to nip that in the bud.

(another problem is that layout editor is 1636px wide and is not scrollable - but "import", "export" and "apply" buttons are at the left side so should be onscreen even in most dire cases, so loading standard layouts should not be a problem. Need to look though, may be making it scrollable is easy, or on small screens it kind of makes itself scrollable - Qt is pretty damn smart.)

[DMA]

Mac: normal, multimedia and system keyboards work. Machine doesn't stay in sleep - probably because lacking USB suspend support.

BIOS: normal keyboard works. So my hypothesis is true, you don't need separate boot and NKRO reports, just make system keyboard report longer.
You will lose USB 1.0 compatibility (64-byte packets come with "Full speed") - but then again, I don't think my hardware supports that.

Now for the suspend support, flight controller compilation can wait.

[DMA]

Had some struggling with suspend (bit arithmetics bit me again) - learned how to send selective suspend (SET_FEATURE (23 03) to hub, value=port, index=2, length=0).
100% of USB 2 Command Verifier Chapter 9 tests pass normally.

11mA in suspend mode - can fight for less, don't see much point in that now.

I know A LOT about USB 2.0 now

Next step - trying to run controller on other platforms, and building static (or, at least, redistributable) FlightController version.

[DMA]

Built static version of FlightController on windows. FlightController.exe, no external dependencies, 16 megabytes.
Compiled on Windows 10, works on Windows 7 x64.

[Techno Trousers]

Those are some great updates. It'll be really nice to have a consistent sleep mode, and I totally agree that 11mA draw in suspend is not worth fretting over. We're not chasing Energy Star certification.

[DMA]

Unfortunately, building Qt apps on OS X sucks. Qt5 requires xcode - which is 5GB download and the download speed leaves a lot to be desired.

But, while waiting for downloads to complete, updated firmware to 6.2kHz scan rate by adding intermediary DMA buffer which allows to read results from ADC and process them in parallel. CPU utilization is almost 100% now at 36MHz, and current consumption is 28mA.
Switched to 48MHz CPU/12MHz ADC, got 5.3kHz @30mA, 13mA suspended, with CPU to spare.

[lot_lizard]

Hey DMA... I don't have long, and will check the response tomorrow... but wanted to see if you were really ready to have a vote about this controller for the MF, and if there was anything else you needed from me to be comfortable. Looking at the posts quickly, I "think" you are. In regards to the concerns about space, given your tiny footprint, the controller would even work rotated at 90 degrees if you felt that connection was better for the slip-on connection to the PCB (even in the SSK). You sent me a PM about it before. Let me know, and I will start a poll in MF-land

[DMA]

Welcome back, ll!
Yeah, I'm ready, realistically mac os build is the only thing left on a critical path, and it should be done today (Downloading the second version of XCode right now - Qt requires a pretty ancient one and doesn't work with newer.)

I think 90 degrees is safer (I worry about touching the ground) though it will require a separate ground line. Or it may be better to make PCB larger because mounting posts are already there.

Want to include "yes, but I really need macros" item, and want to see configs with complex layers and macros. I'm asking because 1) I want to see real macros to see what commands are in use and 2) I have 1216 bytes left with 4 layers. That's enough for 9 additional layers. So should be there 8 layers and 700 bytes for macros (which will take a bit more space than xwhatsits') or it's better to leave it as it is now.

typed on the 5251

[DMA]

Yeah. Managed to build on OS X - second XCode attempt and some woodo with @rpath were required.

And, since macos apps suck so much without proper icon - Flight Controller now has an icon.

icon_512x512@2x.png (1.43 MiB) Viewed 9411 times

brb, need to make another 9 versions of it.

[DMA]

Done.

http://jwbh.ru/CommonSense/ - has windows and mac apps. With icons

The Brave can run and see if it runs. It will start with no keyboard - not much can be done though.

[seebart]

Done.

https://github.com/dmaone/CommonSense/t ... ase/0.1.0/ - has windows and mac apps. With icons

The Brave can run and see if it runs. It will start with no keyboard - not much can be done though.

Respect. Testing shall commence.

[DMA]

Respect. Testing shall commence.

Please use the new link - github is not really a place for binaries.

Also will show me some download stat - I understand it will be zero downloads, but it's better to have some proof

[DMA]

Linux hidapi is lacking - can't tell device usage and usage page. This leads to guesswork - right now the workaround is "filter by vendor_id and get the second device". Because every interface is it's own device for hidraw driver, it seems. Hello conditional compilation.

I'm inclined not to provide binary linux version - I'm not even sure there will be actual users. I mean people who don't have windows or mac machine around to configure.
I've got to the stage where I can compile the application, but building static version of Qt on a virtual machine..
"Accepting pull requests"

[__red__]

Which reminds me, IOU a pull request

[DMA]

Which reminds me, IOU a pull request

I actually wrote a build script. It will still require installing 3 packages from default ubuntu repository - but it's more or less automatic.

The only thing unclear is how to make default device permissions so that not only root can access them.

Update: Actually, ubuntu has libhidapi-hidraw in packages. So, aside from standard system, nothing is needed. So linux guys have it a bit harder than the rest, but palatable. Just need to update the instructions.

[DMA]

"Update FW" button uploads firmware now, not just puts the device into bootloader mode. Should have done this first, would've saved me hours by now
Also folders are remembered across runs, so it's not navigating from "My Documents" all over again.

[micrex22]

What about a release for ArcaOS?

I actually could engage some OS/2 developers who might be interested in assisting on porting the software over

[DMA]

What about a release for ArcaOS?

I actually could engage some OS/2 developers who might be interested in assisting on porting the software over

Not sure if Qt runs on that.
But even if it does - hidapi library will need to be ported.

But yeah, supporting OS/2 would be a venerable goal.

[micrex22]

Not sure if Qt runs on that.
But even if it does - hidapi library will need to be ported.

But yeah, supportibng OS/2 would be a venerable goal.

Looks like Qt for OS/2 is a go: http://trac.netlabs.org/qt4
But I can't find anything for hidapi, so the linux version of hidapi would have to be ported over (which should be possible; Paul Smedley has converted so many Linux applications to OS/2).

Spoiler:

He actually had a rather interesting video on the subject:
https://www.youtube.com/watch?v=Vw6bhDH8Oig

[Techno Trousers]

OS/2. Now that takes me back! Microsoft should have bitten the bullet and gone ahead with it instead of NT.

[DMA]

Looks like Qt for OS/2 is a go: http://trac.netlabs.org/qt4

qt4 is a no go, it's horrible.
Still, you must have something to run VMs in - surely you need to run stuff that's not ported.
FlightController works in linux-under-virtualbox, so you aren't completely in the dark.

[DMA]

Updated matrix monitor module to the data acquisition station. Sort of. It now shows min/avg/max values for every cell and allows export to CSV.

Run 3 F122 PCBs thru it (Thank you again, lot_lizard, for your hardware contributions!) - turns out they're pretty similar! One thing surfaced - if you press 1 key and get reading of X, and press adjacent keys - you can boost it a notch. To X+2 may be. But if ALL keys are down (which is the case when you remove keycaps) - it goes back to X.
So the noise floor is very similar, but PCB 1 shows higher "pressed" state because of that. Had to remove caps to close the frame. Got to "open/close model F assembly in 15 seconds" skill by the evening - but not with keycaps. You need inhuman force to do that - which is fine by me - but you also risk breaking off flipper legs, which is NOT OK.

Looks like the metal case is not just the EMI shield, but a vital part of the sensing mechanism. At least the lower part. Will test more tomorrow, when it's daytime and those LED lightbulbs aren't howling on all frequencies of the EMI spectrum

Data are here in case anyone is interested.

Also sorted scope screenshots by category, named them (hopefully "named appropriately"!) and put on github. Probably imgur is a better place, but..

In particular, there's reason for capsense finickinness in those shots.

Better scope allows one to see that what looks like clean, perfectly impedance-matched waveform, easily detectable by a simple comparator


is, in fact, an abject ringing horror


which has peaks of practically the same magnitude, no matter the state of the actual key.


Those peaks are short, but they're high enough to trip the comparator. And the only way to get rid of them in mass production is to severely underdrive the matrix, so there's ABSOLUTELY NO CHANCE for this to happen. Which by itself is a dead end if you're trying to shift the ground - because underdriving significantly weakens the signal you see on the other side of the capacitor.

In other words - we're lucky Tom Wong-Cornall's scope wasn't too good - he might have considered what he's trying to do to be impossible
Luckily, the same thing which drives scope resolution and sample rates up - namely, progress in ADC engineering - allows to read those weak signals reliably. Unless you use Kinetis K20, of course

[DMA]

Experimented on PCB #1 today.
Data here.

1) Removed ground from rows 1-7 - a progress photo.
Noise jumped 2x, signal 1.5x. Still worth it, because while noise jumped 2 points, signal jumped 4. Allows for wider deadband.

2) Made vias in 2 pads. The effect appears to be ~3x stronger signal, with negligible effect on empty pad. Removing shielding makes signal stronger - less capacitance on the receiving end means same amount of energy produces higher voltage.

Reducing pad area to bottom 10mm doesn't cause noticeable degradation in ungrounded scenario.

Routing rows thru flipper legs doesn't affect sensing in any way.

Gap between conductive surface and PCB matters _greatly_ - would explain those overshoots when the flipper lands.

Bottom line: PCB routing for phase 2 can be made less problematic, but those bolt holes ll wants to be in all four corners of the barrel frame, will need to be closer to the top, where flipper legs are.
But I still think a prototype run will be needed to validate this.

For phase 1, though, I _STRONGLY_ recommend adding vias to the column pads, near the top of the pad. Would recommend this for Ellipse's project too, but I don't know him and for some reason think he'll be VERY reluctant to change anything at this point
But via path is cheap, safe and will improve signal A LOT - for me, threefold increase in SNR is a no-brainer.

[wcass]

Were tests done with test switches sandwiched between steel back and barrel plates? I would have thought that the effect of the ground trace (25 mil away from the column) would be negligible compared to the effect of the grounded back plate (maybe 5 mil away).

Electronics design has change a lot in the 35 years since IBM made the Model F. I am not an originalist, so i see good reason to try to improve the PCB design.

[DMA]

Were tests done with test switches sandwiched between steel back and barrel plates? I would have thought that the effect of the ground trace (25 mil away from the column) would be negligible compared to the effect of the grounded back plate (maybe 5 mil away).

PCB was retained on standard pegs F122 backplate has. So PCB + backplate, may be just a bit farther apart than normally.
Top plate was off - too much hassle constantly flipping it on/off. For something that only noticeably shields outside electromagnetic fields, at least. If it materially affected sensing - would be another story.

Ground trace goes between driving and sensing pad - this a) disrupts the "driving pad - pcb - sensing pad" path, and b) drains from the flipper at least some charge passing thru it. I wasn't smart enough to just remove the section between same-key pads first and look at the result. In my defense I can say that peeling traces with an x-acto knife is far from easy
Can do this tomorrow if you're interested - PCB #1 still has about 9 columns unmolested.