CommonSense: matrix LCR meter with a HID interface

[kmnov2017]

@PancakeMSTR what part of picture is unclear?

@JP! - yes, ExpHdr pins are for that. ExpHdr_0 and ExpHdr_2 will be solenoid driver active pins if you select "solenoid" in hardware setup.

• How do I wire the 3278 pinouts to the controller?

• Do I use xwhatsit's solenoid driver?

• What do I do once it's wired up?I.e., what steps do I need to take to program the controller once it's wired up?

Any help is greatly appreciated.

The steps are defined here: https://github.com/dmaone/CommonSense/b ... /README.md

You have to visually inspect your 3278 to figure out the rows and columns. But generally the last 4 are rows, the rest are all columns, except for the very first one (from left) and one just before the rows begin. These two are ground.

The solenoid driver is compatible with Cypress

The Cypress kit costs USD 10 only in the US, I haven't seen any in Europe for less than 25 euros (almost USD 30).

[DMA]

So, since I'm no longer actively fixing things anyway, and the only KP was the macros (which had some defects, and which I totally broke when migrating to 8-bit keys) - and I fixed that..

I christen thee Release One Point Zero, codename "It's not just good, it's good enough!".

https://github.com/dmaone/CommonSense/releases/tag/1.0

If you had tap and press macros on the same key - delete one of them and recreate, because Firmware counts on FlightController to position tap macros before keyDown ones for the same key. If keyDown goes first, tap macro will never trigger.

It is now possible to have all 3 macros on the same key. *Theoretically* tapdance macros are also now possible but fuck that I'm not doing it - key processing state machine is clowny enough as it is.

Windows version only for now - I'm on hard PTO and my work laptop is at work. When I'll get there, I'll amend the release with OSX app.

[DMA]

I changed the default pinout (and added a picture of it), so that you only need to desolder things if you want to use column 24.

Added "default firmware" - which is, by definition, half-assed. I don't know what's the matrix size of your keyboard, and making it configurable via FlightController makes scanning considerably slower (I tried 2 years ago).

Explained the ExpHdr thing - and also why I don't want people who don't know what they're doing to even think of touching it.

Also made contract a bit clearer in README.md, because 2 cases of "I want to use this thing you made, I don't want to read instructions to figure it out, YOU OWE ME TECH SUPPORT" warrants clarifications.
Short version - if you're not lot_lizard, Miurium, Sangdrax or wcass (alphabetical order) - no, I do not.

If I have time - I will help, but do not assume that my time is cheaper than yours (it's likely not - not for me, at least), make reasonable effort to figure things out yourself. I also accept pull requests - for documentation, at least - so if you figured it out, you can submit a PR, I'll semi-blindly accept it.

[kmnov2017]

Excellent write up! This basically solves most open questions.

[kmnov2017]

On github, the updated readme has the following as the base setup

D0: 0.2. Must be connected to the nearest GND.
Guard: 0.3. Must be connected to the nearest GND BY A SEPARATE WIRE
ADC Vref: 0.4. Must be connected to the nearest VDD.

However, the previous write up had
Vdd connect to 0[2] and 0[4]
Gnd connect to 0[3], 3[2] and 0[7] (last one must be connected to closest Gnd)

So, I guess I have to change the wiring, if I want to flash this firmware.

[DMA]

Read headers too! They really help!

The default project is "8x24" now. "Firmware", for compatibility reasons, will still have old pinout.
No guarantees of not changing config.h in "Firmware" project tho.

[kmnov2017]

So here's a quick update:

After wiring by the Cypress board (i used the prior default config), flashing the firmware (i used CommonSense.cywrk to compile the firmware) and wiring up the keyboard and after successfully connecting to the keyboard via Flight controller; I did the following:

1. Set the thresholds

2. Once I got the threshold values, I went to threshold editor and per DMAs guide on Github, added an incremental value of 5. Most of my thresholds were under 7, so adding 5 roughly doubled the values.

3. I then opened up the Layout editor. When you a press a button, YOU NEED TO HOLD IT DOWN FOR A FEW SECONDS before the pressed key shows up. Assign your value based on the pressed key. If you have another keyboard connected (or if you are doing this on a laptop), just press the desired key on the other keyboard (or laptop) - This way you can set up the layout fairly quickly.

4. I did a commit. I got the message successfully flashed on to the EEPROM.

Now this is the part I am stuck. After the commit and closing Flight Controller, I was assuming the keyboard is configured and ready to use. But no, I can't get the keyboard to work. Pressing keys doesn't register anything. I read the Github guide all over again, I am not sure what I missed....

[DMA]

2. there is a phrase there about setting thresholds halfway-3/4 between resting state and pressed state. That's how you set them.

3. You shouldn't hold the key down for a few seconds - after you set thresholds, apply, upload and press keys. they'll light up yellow. Very quickly, should not be any percepted delay.

Sometimes exiting setup mode doesn't work when you close FC - so either click yellow status bar area and then close FC, or just pull out the keyboard and plug back in. But in your case I'm pretty sure you fucked up thresholds. There's another important note in the
"configuring" section - "If it's a beamspring, read everything inverted".

[kmnov2017]

Sometimes exiting setup mode doesn't work when you close FC - so either click yellow status bar area and then close FC, or just pull out the keyboard and plug back in.

THAT was IT. All solved now! I am typing on it now...

I learned a lot. Including how to compile hex files and what not....

A big applause for your work!

[kmnov2017]

A few open questions though:

1. If I want to reuse an existing cypress board (say for a future project), can I just reflash a new firmware on it? For example your new default hex file for the 24x8 matrix?

2. If yes to the above, I will have to change the base pins per the new layout you have described.

3. If I have to use this on a beamspring, do I need to recompile your default hex file (because the switch type on your default is set to BUCKLING SPRINGS)? Or it doesn't matter as long as one knows how to interpret the thresholds (Max -> Min, and adjustment of thresholds is 75% of the "monitor" values)?

[DMA]

1. yep. if you use the same bootloader - you can even do it from FC, "Update FW" button. If not - go normal route, using the KitProg.
2. can't really understand. pin mappings are determined by firmware. Process is described in the README. You upload firmware using pins for different things - you can't expect it to magically solder itself.

3. Unfortunately, I can't increase font size of README.md above this size. So bear with me.

Please.
Read.
The.
Manual.

[kmnov2017]

2. By base pins - I mean the following

D0: 0.2. Must be connected to the nearest GND.
Guard: 0.3. Must be connected to the nearest GND BY A SEPARATE WIRE
ADC Vref: 0.4. Must be connected to the nearest VDD.

This is different than what’s on my cypress board. I have what you described in the previous version:

Vdd connect to 0[2] and 0[4]
Gnd connect to 0[3], 3[2] and 0[7] (last one must be connected to closest Gnd)

So, if I change to the new default firmware, I am assuming I need to change the base (or default or whatever you want to call it) connections.

Sorry, I am not technically aligned and until I will continue to have these questions.

On a lighter note, how I wish if things would solder up automatically (ahem )

3. Same as my comment above, I am not technically aligned like 99 percent of the audience on this forum. I have read your guide and I know that default is set for buckling springs, I just don’t know if anything changes (other than the readings being interpreted the inverse way) for beamsprings.

I gather from your rather snarky comment that a new hex file has to be compiled.

Maybe it helps the community, if it’s possible to also upload a precompiled version for 23x8 beamspring hex. Just a suggestion (or else I’ll do it)...

[DMA]

Oh, come on. Please, PLEASE go and READ THE README. It says right there that default pinout project is now called "8x24", and that if I were you I would COPY it and what copying would mean.

You can't do precompiled 8x23 hex. Beamspring produces high signal when keys are not pressed. Rows and columns not on your PCB will be pressed all the time.

And it's, like, in **bold** right over there that if you not doing any deviations from **things in bold** - you can get away with not compiling. It says that it is a shortcut. I rue the day I decided to include "default firmware"
I'll think a bit and probably just remove it.

Update: Seriously, I don't know how many times I should say it in the doc. Current text:

If you plan to change anything (and I recommend at least bringing number of rows and columns in sync with your matrix) - skip this section.

**IF** you plan to use vanilla firmware (which will have **8x24** matrix, **default pinout** and will expect **buckling spring** switches) - you can get away with smaller download. You will still need a Windows machine though (see next section for "Windows machine" notes).

It says TWICE that ANY CHANGES require recompiling.
Your switch type is not "buckling spring"? RECOMPILE. As simple as that.

[snacksthecat]

Let me air my ignorance for a moment (since that's apparently my favorite thing to do on this forum )

First of all, really good updates to the readme. I think a lot of gaps will be filled for people.

My question is about this part:

ExpHdr (AKA "Solenoid connector")
Configured to blink the kit's LED on keypress. 12.4 is a CapsLock LED, 12.3 - NumLock.

Leave it alone, unless you really know what you're doing. You can permanently damage GPIOs if you fuck up here.

DO NOT POWER ANYTHING FROM GPIOs. Max GPIO source current is 4mA. FOUR. MILLIAMPERES.

So, ExpHdr0(12.3 by default) would be "enable" line, and ExpHdr2 (2.1) is the "fire" line. Delay settings are in "Hardware" section of FlightController. ExpTgl "USB scancode" toggles between normal operations and "all GPIOs are pulled to the ground".

Does this mean that I would need to build some sort of driver if I wanted to hook up a buzzer (in lieu of a solenoid)? At 4mA, would I be basically be asking it to power a blender?

[DMA]

Does this mean that I would need to build some sort of driver if I wanted to hook up a buzzer (in lieu of a solenoid)? At 4mA, would I be basically be asking it to power a blender?

There was this "xwhatsit solenoid board" - you should use that. I'll try to update the doc.

[swampangel]

Does this mean that I would need to build some sort of driver if I wanted to hook up a buzzer (in lieu of a solenoid)? At 4mA, would I be basically be asking it to power a blender?

[noob thoughts] If you google for "arduino buzzer" tutorials, lots of them do just use a gpio pin to power it, so it seems possible. But here's a simple/safe circuit switched by a transistor: https://startingelectronics.org/beginne ... no-buzzer/

Some buzzers have a 3 pin variety where this is built into the package, and you connect the control line right to an io pin: https://www.dfrobot.com/blog-947.html

[snacksthecat]

Cool, thanks guys.

[kmnov2017]

I am trying to get the 8x24 project to work on a beamspring. I built the bootloader and the 8x24 project first without any changes - the build worked all fine. I then changed Config.h on the 8x24 project to reflect 24 Columns and 4 Rows and changed switch type to Beamspring. When building the firmware I get this warning:

2019-08-06.png (20.16 KiB) Viewed 12084 times

I was still able to flash it though on the cypress controller.

FIRST QUESTION:

Does this warning message have any impact on the usage of the controller?

SECOND QUESTION:

In Flightcontroller, when loading a predefined keyboard initializing file (I used 5251.cfg), in Key Monitor, the matrix changes to 16x8. So I am assuming this can't be used (Since I need at least 23 columns to match the beamspring)?

THIRD QUESTION
To get around it, I reset FC by disconnecting and re-plugging the keyboard, I went in to Hardware settings and tried changing values. Uploaded Config until I got it to Scan. Are the predefined initializing files just to get the hardware settings or is there something else that I need to do?

FOURTH QUESTION
After setting thresholds (I set them on Min values for the beamspring) , and adjusting values (reducing each value by 25% for beamspring). I am able to receive output for most keys (not all). But I see several key presses are generating multiple outputs. In Layout, I can see that several keypresses end up highlighting 4/5 cells on the matrix. I tried adjusting threshold values, that helped a bit but when I applied changes, and went back to Layout, I have the same problem again. I have both the PCB and Cypress board also ground to Chassis.
Any suggestions on how to fix it? I maxed the debouncing steps as well, didn't help with the problem.

FIFTH QUESTION
For those of you who have converted a beamspring with cypress, can you state what Hardware settings have worked for you?

I've had the multiple key press issue even for the following settings:

ADC: 10
Charge Delay: 253
Discharge: 65533
Debouncing Steps: 16

[darkcruix]

I am pretty much at the same stage as kmnov2017. I have a 5251 with a 23x4 physical layout and wired everything up according the below diagram.

Spoiler:

PinOut 5251.jpg (793.38 KiB) Viewed 12056 times

When I compile the firmware (8x24) with settings:
COLS: 24
ROWS: 4
I get the same warning and have a hard time to get key presses registered at all

Likely my wiring is incorrect or I am just too stupid to understand the readme. Any help would be appreciated.

[PancakeMSTR]

Also in the same boat with darkcruix and kmnov on the 8x24 project.

[DMA]

@darkcruix when in doubt you want "star ground" - i.e. everything having it's own ground wire converging on one point. This should not matter for this project though.
Please double-check you connected ground on BOTH sides of the PCB - on newer beamsprings there are no vias so PCB grounds are separate on each side, and having a floating trace which weaves around all the keys can cause all sorts of trouble, especially in beamspring (because it's flippers are down at rest, allowing the signal thru - unlike model F).

I can't really check the actual mapping you have from the picture you posted - it looks nice, but as you probably noticed when soldering, 30 parallel long wires of the same color are not easy to trace. It looks close to what it should be, but..

Also please define your matrix for the firmware with EXACTLY THE SAME DIMENSIONS as your physical matrix. For model F it doesn't really matter, but for beamspring all unconnected columns will appear pressed all the time, tripping the safety checks on startup.

@kmnov2017
a) use logic please, and take time to actually read the warnings. The "project" column is right there, not even out of the viewport. It tells you it is not one of the projects you're trying to build. What is the logical conclusion here? It is not relevant.

b) I'll remove ALL the default settings and configs of ALL KINDS next time I'll be committing things.

The README describes how to do it without any defaults. Just do it in steps. Planning => Soldering => Thresholds (+hardware settings if you can't get the signal/can't get stable readings) => Layout. Make sure step X is done right before you move to step X+1. Don't cut corners - this is a minefield, not a park.

This is not xwhatsit which has custom hardware - this is a Lego set of standard bricks. You can build, like, WORLDS from those - but it requires imagination, skill, and some thinking. This is both blessing and a curse. Especially thinking. I hate thinking.

If there will ever be a custom-hardware-controller (well, there's CSSK, but I don't expect more than 2 of those to ever exist, one in acrylic and one in aluminium) - it will be a different story. It will come preprogrammed, with matrix dimensions set according to keyboard it's made for, so all those problems just won't be there. But it will be limited to the keyboard it's made for.

Also come on, if you programmed 24x4 configuration and connected to the actual 23x4 beamspring keyboard, column 24 should be lit up no matter what you do. Is it not enough of a hint that you should configure it as 23 columns?

[PancakeMSTR]

The README describes how to do it without any defaults.

From the [readme]

There are config files in misc/ directory which should be a good starting point.

The README describes how to do it without any defaults. Just do it in steps. Planning => Soldering => Thresholds (+hardware settings if you can't get the signal/can't get stable readings) => Layout. Make sure step X is done right before you move to step X+1. Don't cut corners - this is a minefield, not a park.

Exactly, we are getting stuck on the "Thresholds" step, and are looking to an expert to help us move past it so that we can get stuck on the next step.

Also come on, if you programmed 24x4 configuration and connected to the actual 23x4 beamspring keyboard, column 24 should be lit up no matter what you do. Is it not enough of a hint that you should configure it as 23 columns?

The [config.h file] is not very clear about this. Because there is an ambiguous "issue" with odd number of columns, we figured we'd configure it with 24 columns but only use 23. We don't know the deeper details of this code, and so have to guess about what to do.

[wcass]

This is not xwhatsit which has custom hardware - this is a Lego set of standard bricks. You can build, like, WORLDS from those - but it requires imagination, skill, and some thinking.

Great analogy.

Might i suggest that the part of the keyboard community that can do this - help create more documentation for those that can't. This is a must read. Snaksthecat also did i nice bit with this. I think that some of the guys that are having trouble may not mind shipping a keyboard or paying for parts and labor. If that sounds like you, maybe post to Marketplace > Member to member > Other? I would volunteer myself, but am working on two big projects.

[snacksthecat]

This was going through my mind as I was falling asleep last night: What is the reason for disabling scanning in FlightController if the keyboard is "insane" when it's plugged in?

I was having trouble with getting a bad 5251 PCB to work so I went in and tweaked the FlightController code to allow insane keyboards. Doing that allowed me to zero-in on the bad rows/columns (I don't remember exactly what was wrong but you get the idea). Is this a bad idea?

[kmnov2017]

The 8x24 project still has the old pin assignment in PSOC. We realised this when all three of us (PancakeMSTR, Darcruix and I) all had three dead columns. A closer inspection revealed that the PSOC PIN settings hadn’t been updated to reflect the new pin out proposed by DMA on github. Changing the pin assignments has fixed the problem.

[DMA]

This was going through my mind as I was falling asleep last night: What is the reason for disabling scanning in FlightController if the keyboard is "insane" when it's plugged in?

I was having trouble with getting a bad 5251 PCB to work so I went in and tweaked the FlightController code to allow insane keyboards. Doing that allowed me to zero-in on the bad rows/columns (I don't remember exactly what was wrong but you get the idea). Is this a bad idea?

Scan is disabled by firmware, not FC.

The reason is it will output ~1000 reports per second with essentially random keys pressed and released. Windows is not amused at several thousand keypresses per second, especially when some of them are power/sleep key. But even without - it's usually easier to powercycle than to wait 10 minutes for it to recover and then closing the bazillion of various windows.

There is a trick - not sure if in readme. It should be. Open matrix monitor, press Start. NOW go into main window and press Scan. As long as you don't press "Stop" in matrix monitor, you'll be safe.
OR COURSE config upload/download WILL NOT WORK. I officially don't even know what will happen if you try. But it will allow you to see what controller sees. I'm rapidly losing my faith in people's ability to interpret what they see - but it will allow you to.

[DMA]

The 8x24 project still has the old pin assignment in PSOC. We realised this when all three of us (PancakeMSTR, Darcruix and I) all had three dead columns. A closer inspection revealed that the PSOC PIN settings hadn’t been updated to reflect the new pin out propped by DMA on github. Changing the pin assignments has fixed the problem.

damn. did I forget to save the project or something? I'll fix that. Eventually.

[DMA]

I think that some of the guys that are having trouble may not mind shipping a keyboard or paying for parts and labor. If that sounds like you, maybe post to Marketplace > Member to member > Other? I would volunteer myself, but am working on two big projects.

I actually don't mind doing it essentially for free - just ship the board and controller to me and pay shipment both ways.
Bolting the controller on is literally a 15-minute process if you have PSoC Creator installed. Well, probably 40 minutes if you count _all_ the soldering and wire stripping.

I really, really don't understand what causes so much trouble and why __red__ was able to do it without having a single question, Sangdrax did his foam-and-foil conversions asking me _afterwards_ if I can output num and caps on unused ExpHdr pins (that was first time I even heard from him), and suddenly there are lots of people here who try to convert a standard issue 23x4 beamspring and can't.

Did I screw up the firmware somewhere? I run the latest. Always. (well, my primary is currently at "before macro fixes" because I don't need them. But I have a topre testbed - and that runs 1.0 with no issues). So I don't really think I have. But who knows.

PS: Config updated, docs updated.
Guess what - the "use matrix monitor to see why you trip sanity checks" was documented as - TADADADAM - "Debugging the matrix".

[snacksthecat]

Guess what - the "use matrix monitor to see why you trip sanity checks" was documented as - TADADADAM - "Debugging the matrix".

My bad on that. Thanks for clarifying the reasoning above and for pointing me to the right spot in the readme.

[darkcruix]

At first, I am writing this with my 5251 and CommonSense as controller. Below is just a little write-up of my experience.
I did read the full documentation and followed the steps. While I am far from being an expert, I have to admit, I had some troubles getting it to work in the beginning due to a few reasons:

• The grounding is paramount

• The connector on a BeamSpring needs a tight fit or you need to solder the wires

• There were a few Columns it didn't detect and it took us a while to figure out the reason (see earlier posts)

• Enter the right rows and columns in the project

Once all the above is sorted, the rest of the process is reasonably simple and works after following especially the Threshold process.
Apart from DMA I'd like to thank kmnov2017 for comparing results and tips & tricks.
Not everyone will get this working out of the box and some initial "getting used to" is definitely something to mention. The versatility of CommonSense is awesome and also the FlightController is easy to use, imho.