[Done] CommonSense: matrix LCR meter with a HID interface


27 Aug 2019, 16:38

tigpha wrote:
27 Aug 2019, 16:22
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 :)

User avatar
[ XMIT ]

27 Aug 2019, 17:42

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.


27 Aug 2019, 17:57

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.


27 Aug 2019, 20:43

PancakeMSTR wrote:
27 Aug 2019, 16:11
tigpha wrote:
27 Aug 2019, 15:26
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.

User avatar
[ XMIT ]

27 Aug 2019, 20:59

tigpha wrote:
27 Aug 2019, 17:57
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.


29 Aug 2019, 08:33

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..
PancakeMSTR wrote:
26 Aug 2019, 18:11
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 :D ) 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.
PancakeMSTR wrote:
26 Aug 2019, 18:11
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).
PancakeMSTR wrote:
26 Aug 2019, 18:11
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.
PancakeMSTR wrote:..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.
PancakeMSTR wrote:
26 Aug 2019, 18:11
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.

User avatar
[ XMIT ]

29 Aug 2019, 12:37

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.

User avatar

26 Sep 2019, 00:16

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?



26 Sep 2019, 04:21

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

User avatar

26 Sep 2019, 04:51

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


26 Sep 2019, 06:26

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

User avatar

28 Sep 2019, 00:27

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?


28 Sep 2019, 03:39

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.

User avatar

01 Oct 2019, 01:19

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:

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


01 Oct 2019, 01:42

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


07 Oct 2019, 04:49

New push
* cortron docs
* contron kitprog-based "brain transplant" (needs a little bit of tuning)
* FlightController - 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.

Post Reply

Return to “Workshop”