CommonSense: matrix LCR meter with a HID interface

[PancakeMSTR]

Please persist my good Pancake Master. You have already reached further than I was able. Your tribulations may serve to enlighten me, and save me frustration from future obstacles when I eventually resume tinkering with Common Sense

At your service

[XMIT]

I want to get set up with this. I've ordered two of these Cypress dev kits. If someone has a spare to donate I'll gladly take it. I've got a couple of Beamsprings and Fs that I can play with, and the evil self serving goal of building myself an FEXT full sized Model M->F board. Also it's an excuse to ping DMA again, it's always a fun time.

From some perusing it looks like all their build and tool chain stuff is Windows based. Sigh. I know it's a pipe dream but a first class Linux workflow for MCU cross-compile, programming, and maybe even emulation would be ideal.

[tigpha]

Hi XMIT, agree that a complete Linux tool chain would be peachy. But loading images is not a frequent operation unless deep hacking of controller source code is required.

I can subvert the corporation laptop to install the Cypress dev kit should I need to upload binary images to the gum stick. I tried to use a virtual machine image on Linux to install and run the Cypress tools, but abusing the doled-out Windows machine proved more productive.

[kmnov2017]

Just to add: this is a *hobby*, something we all do in our own time and when we have spare energy. It's not a trade, nor barter or any other exchange, but a *gift*, and should be accepted as such. Y'know, gift horse and mouth and all that?

Also I can't get my layer mods settings to persist beyond layer 1.

When you set layers, before you switch to another layer in Layout, make sure you click Apply.

[XMIT]

Hi XMIT, agree that a complete Linux tool chain would be peachy. But loading images is not a frequent operation unless deep hacking of controller source code is required.

I can subvert the corporation laptop to install the Cypress dev kit should I need to upload binary images to the gum stick. I tried to use a virtual machine image on Linux to install and run the Cypress tools, but abusing the doled-out Windows machine proved more productive.

I find that programming firmwares with anything but a dedicated Windows system and a direct connection to a USB port is the safest thing. No hubs, no virtual machines, no funny business. The hardware is often expecting particular timings or timeouts and there is too much uncertainty otherwise.

Yes, I've got a crummy old Windows laptop sitting next to my Linux workstation for exactly this reason. But I cry a little bit on the inside every time I need to turn it on. I wonder what it would take to make this or any MCU a first class supported target under clang/LLVM. A robust description of the instruction set, memory sizes, etc.

[DMA]

Oh that feels so 1996 on so many levels. The Great Flame Wars of Russian FIDONet.
I'll read about tact after I'll hit that sweet "Submit" button, but for now..

we are providing information to DMA on how to improve his product by reporting on issues we encounter

Here's the thing. There is no "product". Or, rather, "the product" is not what you think it is.

This project costed me ~2k5 USD so far. Material and purpose-bought tooling only.
The Primary Deliverable sits on a nondescript desk in one of the many Seattle office buildings.
It's not The Most Expensive Keyboard Known To Mankind, but somewhere in top 100 I guess.
This is as close to "the product" as it will ever get.
It doesn't need an improvement - that ocean has boiled and all the yaks that were swimming in it are shaven clean with the saw I hand-sharpened.
It runs firmware v0.1 from about a year ago.

It is built around community effort. I mean PHYSICALLY built AROUND it: the top plate and sense card are Muirium's instance of the XTant kit, s/n 5 out of 10.
A gift.
There was a small piece of paper inside the box, reading "A FORGOTTEN PROJECT WILL RESURFACE AT THE PERFECT MOMENT".
I don't know where Mu got that fortune cookie, but that's one of the things I'll remember till the very end. Probably the only thing - I can't remember anything past ~2 years back.

Yes, I now have a metcal (thanks Parak for the introduction to the world of expensive soldering irons ) and a 1054Z and that enables me to do weird stuff like fixing a tire balancer at the only tire shop in whole PNW who care to spin the wheel _after_ attaching the weights to make sure it's still 0/0 - because I like a good riddle and don't like driving 30 miles to hear "you have to come back when it's colder outside, the balancer only works on colder days now".
But those were bought for the project. GAAP says I can allocate costs that way, so I will.

If DMA were smart

Finally. Somebody else recognizing I'm not smart. I am Greatly Relieved. (only like 30% sarcastic here. Prokhorovka pales in comparison to my battle with an impostor syndrome).

Although, to be fair, that kind of exchange of information is exactly what I would call "open-source."

I feel the shoulders of giants already.

..could be used by DMA, and possibly others, to improve..

I'm literally *drowning* in pull requests. In the last 3 years, I received 0e0 pull requests. See, the number is so large I had to use scientific notation.

What DMA fails to realize is that he has a very valuable resource in us, just as he is a very valuable resource to us.

I am not a resource. You're not a resource. Please stop objectifying people.
I mean you can continue objectify yourself if it's your thing, but don't do that to me. please.

==

Despite claims, I'm not providing - and even cannot provide - ALL THE WORK.

I made a thing. For my personal use.
I left all the code in an easily accessible place, and made a reasonable effort to preserve enough domain knowledge so me-3-years-later can walk this path again, not losing too many limbs on the minefields.

It was more than 2 years ago, so I no longer know much more than you do.

I may have better tools - but I cannot lend you those over the internet (although if you're in Seattle area - I may have time to look at your hardware if you bring it to me. PM.).

It is Real World, things break all the time in various ways, and then you die. I don't have the power to change that, sorry.

==

XMIT, start with model F, leave beamsprings for phase 2. Worst come to worst - you can pull the PCB out and use your finger/single flipper to figure out what pads don't work.
With beamspring - all empty pads are PRESSED KEYS and it's harder to figure things out because of the key spam.

I also have a word for you: "VirtualBox". Yes, I tried.

I also spent about 3 days trying to run cypress dev environment in Linux and did not succeed. It uses .net, but it's not the .net mono provides. I managed to get main window to open, but it produced megabytes of error messages and I abandoned.

Anyway, you only need to flash firmware once. Everything else is done via FC (even subsequent firmware flashes. You still need a VM to build the firmware - but the .cyacd can be just copied to linux side and flashed using FC).
Happy hunting.

[XMIT]

I've had mixed success with VirtualBox and firmware flashing for other projects. One is what I suspect is a timing issue. The other is that sometimes the USB target device to be flashed will change its USB identifier suddenly. Sue VirtualBox can be set up with rules to capture said devices, but it helps to do this before the fact. So sure maybe it could work, but since I already have that Windows laptop sitting right there, I'll squander my limited time on other problems.

DMA you raised an interesting point with dealing with key spam. The way I've dealt with this in the past is to set up a separate Linux host, connect the keyboard to it, disable support for Ctrl Alt Del and other shortcuts, and then connect to the host over SSH, remote X, RDP, VNC, what have you. Then you can open up whatever tool you need and inspect the zero levels of the board interactively without having it spam your remote console. The keyboard will be spamming locally, though. I had to do this when configuring my F107 with xwhatsit. Among the keys being held down due to a misconfigured zero were Ctrl, Alt, Del.

For this reason it could be nice to have the keyboard be able to come up in "matrix only mode". This is to say, the keyboard can report state on which sensors are active, but not send any key codes.

Somewhat related, I've found some USB to Serial adapters to be finicky on their own, more so when stacked atop a VM.

Anyway, all of a sudden I have a lot more free time for this sort of work, so maybe I'll be here now often once again.

[jerkstore]

Hi DMA, I see from the title change that you were able to get inductive sensing implemented as well. That's awesome! Really nice job with everything.

I'm curious about Cortron/magvalve switches that have four pins. For the rows, the traces go from an IC to each switch in the row, then back to another pin on the IC. Does this need to be mimicked when connecting it up to the CY8CKIT-059?

[DMA]

Ohh.. I owe the docs.

Also this one is much, MUCH more finicky to setup. 1 out of 3 keyboards straight doesn't work yet, firmware will lock up on empty EEPROM, so you'll need to flash 8x24.cydsn first, open in FC, set delays to 30/4, save config and ONLY THEN flash MagValve.cydsn
And if something doesn't work - 100MHz oscilloscope is BARELY ENOUGH - I really wished I had the 5074 for this. 10mV 50ns pulses are hard to reason about - especially when keyboard length is 9 (yes, NINE) nanoseconds.
Do I need to mention that you'll need to blindly adjust thresholds? I found that 5 to 10 work mostly OK, but your mileage may vary.

but I can explain some things at least.
So cross-section of a MagValve looks like this:

Code: Select all

 __   __ 
|  | |  |
| ===== |
|  | |  |
|  | |  |
|  | |  |

where ===== is a ferrite ring (careful with soldering, it's fragile AF). So they are transformers.
The row is the "left" "winding", and column is "right" one. The other end of the rows is not connected back to the IC - they're connected to ground.
The columns are a bit more interesting - they are connected to diodes which are shorted together and that common point is connected to the comparator input via some resistive divider magic I couldn't fully decipher.
Anyway.
Far ends of both rows and columns should be connected to ground. The jury is still out on "should those be 2 separate wires" - because 2 devices work both ways, and the third doesn't (half of the matrix doesn't register - not a single column nor a single row. Random half of the matrix ).
But I would make it a separate wire, because driving current is pretty significant - I basically short the GPIO to the ground for 38 nanoseconds and hope it will not go poof.

[jerkstore]

Thanks for the explanation. That definitely clears some things up for me.

I actually started trying to wire things up tonight and I got as far as the bug you mention where it freezes up on an empty EEPROM. What I'm getting is a variation on that. These are the steps I'm doing:

1. Flash 8x24.cydsn
2. Open FC
3. Hardware: 30/4. Apply. Save config
4. Flash MagValve.cydsn
5. Open saved config
6. Upload
7. FC freezes

[DMA]

..firmware freezes on me, not FC.
Don't save config - upload and commit. You want to initialize EEPROM, not create a config.

Update: pushed the fix - pull and it should auto-set minimal safe values on startup if EEPROM returns unsafe ones.

Update: spend an hour resoldering the ITW. Switch leads are made from some material that refuses to be wetted by SnPb solder. It can be convinced to do so, but needs A LOT of convincing.

[jerkstore]

Cool, the workaround worked like a charm. I'll give the updated project a spin in a little bit.

I had a question about the wiring, if it's okay for me to ask (I know you're still working on this so I don't want to bug you). I see that it is different from the capacitive projects, but I'm a bit fuzzy on some parts.

I believe I'm clear on these points:

• Controller columns connected to keyboard columns
• Controller rows connected to keyboard rows
• Controller ground connected to keyboard ground

But I'm unsure what else is needed. For instance:

• HPWR - 0[3]

Does that mean I should connect controller Gnd to 0[3]? Also, are any other "base wirings" like this needed?

Edit: And if I plug plug the controller into the PC (without hooking up rows/columns/ground to the keyboard), would it be normal for FC to go to insane mode?

[DMA]

HPWR is for BLE controller to signal it can go and use 500mA from USB. Not needed.
In general, you don't know what is is, it's not needed

Normal if you didn't do anything, as thresholds are zero and who knows what it's reading from empty GPIOs.
Set thresholds to 5, should start and not go insane.

[jerkstore]

Interesting... I can't seem to get it *not* to go insane.

This is what I'm doing, maybe there's something wrong about it:

Pre-info

1. Starting with a fresh CY8CKIT-059 dev board
2. Not soldering anything to the dev board
3. Latest pull from the github repo, no modifications
4. FlightController.exe from the 1.0 release

Steps

1. Build bootloader
2. Build and flash MagValve project to dev board
3. Launch FC
4. Plug dev board into PC
5. Hardware > Delays = 30/4 (I saw you changed the default to 20/4 so I tried that as well)
6. Thresholds = 5
7. Upload
8. Commit

And it always is insane on start up. By doing the scan trick, I could view the matrix monitor and all keys were at 254/255.

I snooped on a row pin with a logic analyzer while doing the scan trick and saw the scan pulses being shot out. Just not sure what the deal is with the columns.

I also tried wiring up a couple of rows and columns to the keyboard and still the same result.

[DMA]

..matrix monitor is supposed to show zeroes on magvalve project. I even plan to gray out the whole thing for inductive switches but have more interesting things to do ATM.

One thing I would do is ground the columns. I discovered that if you leave comparator input floating it leaks so much charge into the input that current flows into the matrix when connected.

You can do it without soldering - open TopDesign from magvalve project, "Sensors" page, disconnect "Listen" wire (ctrl-drag) and connect a logic '0' in it's place - but I understand how it can be more complicated to do if you're unfamiliar with the tool.

[DMA]

New push
* cortron docs
* contron kitprog-based "brain transplant" (needs a little bit of tuning)
* FlightController 1.0.0.3 - switch type output in status bar (tired of worrying to reflash the keyboard I'm typing on), one-click device selection (the dialog most of you will never see).

And off we go - tomorrow I'll wake up, get to the nearest Avis and go wander the US for 2 weeks - estimated 5kmi - to get a firmware upgrade for myself, sort of.

[DMA]

v 1.0.0.4 is out: https://github.com/dmaone/CommonSense/r ... ag/1.0.0.4

It ignores the matrix positions for which threshold is set to zero. Useful if you printed a PCB for your beamspring which has unpopulated pads (like __red__'s 3741)

Would've noticed this much faster if I had an actual beamspring I could use - like 3278 with numpad, or better yet a standard TKL layout with winkeys (a man can dream)

[Sangdrax]

Finally got some new kits in from Cypress directly (the kits have skyrocketed in price from the distributors for some reason so direct is the only real choice now) and had a chance to fiddle with the Magvalve stuff a little bit. I had to update my PSoC virtual components to get the current bootloader to compile as well so everyone make sure all your stuff is up to date.

The new FlightController v 1.0.0.4 was absolutely essential to me. Old version kept locking up when trying to communicate with the kit otherwise. Other than that, I had a weird thing where Row 16 Column 16 kept outputting when I first set thresholds and that was what was making the controller go insane, despite not having a 16 16. Reconnecting fixed that but I'm still not sure what caused it in the first place.

Now just trying to get a couple of columns not registering to pick up. I'll add a couple extra grounding wires where DMA recommended and see if that gets it going. Amazing stuff all around, though.

[Sangdrax]

v 1.0.0.4 is out: https://github.com/dmaone/CommonSense/r ... ag/1.0.0.4

It ignores the matrix positions for which threshold is set to zero. Useful if you printed a PCB for your beamspring which has unpopulated pads (like __red__'s 3741)

Would've noticed this much faster if I had an actual beamspring I could use - like 3278 with numpad, or better yet a standard TKL layout with winkeys (a man can dream)

The way I used to get around this problem is labeling unpopulated stuff as DEAD in the keymap. But it's nice to see it automated

[DMA]

The way I used to get around this problem is labeling unpopulated stuff as DEAD in the keymap. But it's nice to see it automated

Would not save you from tripping the sanity check - it happens before layout translation.

R16C16 key is strange, because it's not physically possible. It's COMMONSENSE_NOKEY and it only can be released - there's nothing in the code to press it. But then again, anything is fair game before first config commit and controller restart.

FlightController hanging (it hangs until you pull out the device, btw) is a sign of firmware crashing. Still happens from time to time when not properly configured (usually because of delays set too short and interrupt arriving too fast, screwing up internal state)

For MagValves, the threshold should be 10 for all 3 of your keyboards. Debouncing must be 4+. Also, in your particular MagValve case, it's enough to only connect ribbon cables. I tested all of it that way. And for columns - let me actually check if I scan all of them.

[Sangdrax]

This is the Harris, which you noted might need extra grounding at a couple points to pick up a couple columns. Those I think are the ones not triggering. I'll have an hour or two to fiddle with it tonight and I'll report back.

Settings right now are Debounce 8, Threshold 10 (though up to 20 works the same so far as I can tell).

Oh, and hope you had a great trip!

[Sangdrax]

The extra grounding worked great. Everything registers now. I'm typing this on the Harris as I speak.

The repeating pressed #16 16 shows up every time I use the upload function. Afterwards, it will still commit and write to the EEPROM but I have to physically disconnect and reconnect the board for it to go away. Reconnect does reconnect but I get the #16 16 back if I don't physically cut power to the board.

Anyway, I have no idea what causes it, but I'll see if it's just this board that does it as I get my other Cortrons converted over this weekend. Thanks again, man.

[DMA]

Wait, you have more than 3?

Also firmware should not send anything using this particular protocol command while out of setup mode. Looks like something triggers that in main loop (I'm patting myself on the back now for adding milliseconds into log timestamps).

Expect v1.0.0.6 over the weekend, probably with 1.1 firmware.

[Sangdrax]

Hooked up my PR1ME and having the same initial problem as the Harris. Everything works perfect except two columns which refuse to register at all. I checked the electrical connection for those pins on either side of the ribbon cable with a multimeter and resoldered everything, even the factory jumpers which looked kind of wonky. Not sure if it's a grounding thing again or I'm being dense somehow. Will report back as soon as I get a little more time to tinker with it.

[DMA]

Sandgrax, sorry, I may be an idiot. The current sense pin drive mode may be suboptimal as in "they will discharge the matrix too slowly and the next drive pulse arrives before transients calm down". Changed to strong drive, pushed out. Please download the new version, build and see.

[fireworm]

Hi, this thread is pretty big; is there a quick summary of how to convert an ITW MagValve keyboard (like a Xerox x998)?

Is it similar to a handwire board, where you solder every switch + column? Or something else?

Edit: nevermind, reading https://github.com/dmaone/CommonSense/b ... agValve.md.

Has anyone converted a Xerox x998 yet?

[Anakey]

Hi DMA just wanted to clarify something.



Rows start at R0 on the picture however columns start at C1. Am i right to assume that C1 should be C0 and so on?

[DMA]

Hi DMA just wanted to clarify something.



Rows start at R0 on the picture however columns start at C1. Am i right to assume that C1 should be C0 and so on?

Yep. It doesn't matter though - you can't configure less than 16 columns with magvalve. You technically can, but you'll need to look at TopDesign.cysch _AND_ the code to understand which columns will be polled.

[DMA]

Due to a freak accident(tm) (seriously tho - I don't know how. I copy-pasted the schematics and dabbled with pin _mapping_, not _settings_) "8x24" project had rows in "strong drive. slow" instead of "pull-up/pull-down". That _may_ explain problems some people had with sense stability. The only way to try is to git pull.

My bad. I'll readily refund whatever you paid me for the software

[cryham]

Hi DMA.
I know it's about 3 years late, but I'm trying your kiibohd fork for Teensy 3.2 with ADC touch sensing, mentioned on page 3 in this topic.
I didn't get far, do you maybe remember what to put in CMakeLists.txt?
I'm guessing ScanModule "CommonSense", OutputModule "uartOut", not sure what for rest, BaseMap "AEK2_Simple", DefaultMap "prototype"?
I got kll error when doing cmake ..
FATAL Could not find 'prototype.kll' DefaultMap
then another when doing make
make[2]: ../kll/kll.py: Command not found
Could be missing kll files or something wrong with current kll repo from master and kiibohd repo from 3years back? Did you change anything in kll? I see you didn't fork it.

Since you mentioned few times that Teensy 3.2 has shitty ADCs (i.e. basically 8 (of 12) bit, rest is noise),
I wanted to ask what do you think about ADCs in such MCUs, for the purpose of touch sensing like in CommonSense.

• "BluePill" STM32F103C8T6 Cortex-M3 MCU pdf here, ADC on page 75. It's very cheap, like 2$ e.g. here.

• Teensy 4.0, Cortex-M7 MCU pdf here, ADC spec on page 60. It's about same price as Teensy 3.2 and way faster.

just for reference Teensy 3.2 MCU pdf is here, ADC on page 37.
How would those compare to Cypress PSOC? Is this something you can tell just from specs or does it have to be tested in real life to know how good the ADCs are for this?

I have 2 BluePills around, I got a PCB made with 3x3 touch keys and I'm also quite into buying Teensy 4.0 (for new keyboard controller base).
My problem with Cypress is that Windows only tool (I'm on Debian 10 now) and that I don't really want to buy yet another, different MCU.