CommonSense: matrix LCR meter with a HID interface

[PancakeMSTR]

So I'm using the updated github source, with the pinouts set appropriately, and I'm running into two problems. One is major, and one is probably minor.

• The major problem is that three of my columns aren't registering, specifically 9,10, and 11. Here is a screenshot of my matrix monitor.

• Second problem: While everything else works nicely in flight controller, I can't seem to get any output from the "good" keys outside of it. I.e.., I can't get the keyboard to type anything in a normal window outside of FC, even though I've mapped keys in the FC layout editor.

Steps I've taken:

• Used most up to date source from DMAs github

• Triple checked continuity, but I'll quadruple check if it's indicated that that's the only thing that could possibly be going wrong.

• Set threshold (set to min, then apply 75% of acquired values)

• Set hardware options to
  • ADC Resolution = 12
  • Charge delay = 100
  • Discharge delay = 7800
  • Debouncing steps = 16
  • Expansion header mode = disabled

I don't know if it helps, but here is a picture of the bottom of my PCB, with how I've wired the columns to the cypress indicated and the offending/non-registering columns indicated in red. Based on the physical condition of the PCB, I see absolutely no indication as to why these columns should not be working.

Not really sure what's going on here and could use some assistance. Thanks.

[darkcruix]

@PancakMSTR:
My problems with unrecognized columns vanished, after:

• I did get 3 GNDs attached to the metal part of the case. I had to attache both top and bottom ground of the PCB and one ground from the Cypress. Once I did that, I got good readings

• The connections from the Cypress to the PCB have been unstable due to the connector I was using. I did the paper trick to push two layers of paper at the top middle and bottom (where there are no connections)

Also, have you tried to

• Flash the Eprom with all your settings

• close the FC completely and even reboot the machine

Sometimes the reboot did the trick at least for registering the keys properly.

Can you post the key assigning (export the layout in text format here). Secondly, how do your threshold readings look like?

Darkcruix

[PancakeMSTR]

@PancakMSTR:
My problems with unrecognized columns vanished, after:

• I did get 3 GNDs attached to the metal part of the case. I had to attache both top and bottom ground of the PCB and one ground from the Cypress. Once I did that, I got good readings

• The connections from the Cypress to the PCB have been unstable due to the connector I was using. I did the paper trick to push two layers of paper at the top middle and bottom (where there are no connections)

Also, have you tried to

• Flash the Eprom with all your settings

• close the FC completely and even reboot the machine

Sometimes the reboot did the trick at least for registering the keys properly.

Can you post the key assigning (export the layout in text format here). Secondly, how do your threshold readings look like?

Darkcruix

• No change grounding both sides.

• I'm confident my connections are good.

[kmnov2017]

Both the PCB ground traces MUST be connected to GND on cypress. Additionally, the two PCB ground traces MUST also be connected to the chassis. One of the cypress GNDs must also be connected to chassis. Without this, I couldn’t get it to work either.

[kmnov2017]

• Second problem: While everything else works nicely in flight controller, I can't seem to get any output from the "good" keys outside of it. I.e.., I can't get the keyboard to type anything in a normal window outside of FC, even though I've mapped keys in the FC layout editor.

steps to correct this:

1. Apply layout.
2. Close layout
3. Click on yellow SETUP status bar below (so that it’s no longer yellow)- This is IMPORTANT.
4. Commit changes to EEPROM
5. Close FC

It should work then...


This should do the trick.

[PancakeMSTR]

Okay update.

Counting from Col 0, wired (the dead columns) Col8, Col9, and Col10 to pins 15.[2,3,4] respectively and removed C41,C42, and R5 from the cypress. This has fixed the dead columns issue.

I sat around playing with thresholds for a while and managed to get almost every key working properly in flight controller. The exceptions are Caps Lock, which fires Tab; and Rshift, which flat out doesn't work.

But I figured it was worth a test, so I set up a map in layout and tried to commit to the EEPROM.

And I still cannot get any output outside of Flight Controller. I've gotten (almost) everything working in Flight Controller but can't get the keyboard to actually type anything! I do not know what I'm doing wrong with this one.

[darkcruix]

Really odd - if it is working in the Setup mode, then it should also work outside of it, if you have assigned the Base Layer accordingly. Can you post a screenshot of the Key assignment and how they registered in the FC main screen? I want to compare it what I see.

[PancakeMSTR]

Here are some pictures of Flight Controller with my Beamspring. Let me know if you would like any more.

Notice that when I commit to EEPROM it says "wrote zero bytes." What is that about?

[darkcruix]

I bet you previously have it written to the eprom, I always did a upload (Ctrl+U) before I wrote it to the EPROM, but that probably doesn't matter.
What happens, if you click on the yellow "Setup" at the bottom of the main FC window? After that, keys shouldn't register in the application anymore but as keystrokes. You are very close to get it working ...

[PancakeMSTR]

I bet you previously have it written to the eprom, I always did a upload (Ctrl+U) before I wrote it to the EPROM, but that probably doesn't matter.
What happens, if you click on the yellow "Setup" at the bottom of the main FC window? After that, keys shouldn't register in the application anymore but as keystrokes. You are very close to get it working ...

No change. I can't get it to register keystrokes.

[darkcruix]

Try to re-write the firmware (8x24) again with the corrected pin-layout. The firmware itself shouldn't actually make a difference, as long as you get the keys registered, but maybe something went south with reading from the layout table.
"Clean and compile" it again, then acquire the connection to the cypress and write it again. After that unplug it and just plug-in the micro-USB port and try again.

[DMA]

• The grounding is paramount

So, what was the exact problem? Loose connector fit or something else? I probably never had it because I prefer soldering of things that don't have proper connectors available (those blue connectors min. board thickness is specified as 1.5mm if memory serves - and PCB is 0.8mm thick.)

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

That now matches the picture. My bad.

[DMA]

Couple other notes.
Rebooting the host is NOT needed. Closing FC is the most drastic action you will ever need to take.
"Upload" uploads your changes to the firmware, BUT NOT TO EEPROM (must I say that's in readme?). "Commit" writes to EEPROM.
"Revert" reboots the controller - same thing as pulling the USB plug and plugging it back.

Stick to recommended settings for charge delay unless you know what you're doing - and you obviously don't. README says when you should increase those settings.

If you close FC - firmware will go out of setup mode after 2 seconds and reset the scan module.

I wish to remind about existence of aquaKeyTest.exe - and if you're on mac, there's built-in keyboard monitor. Those utilities will tell you which keys are pressed.

[PancakeMSTR]

Couple other notes.
Rebooting the host is NOT needed. Closing FC is the most drastic action you will ever need to take.
"Upload" uploads your changes to the firmware, BUT NOT TO EEPROM (must I say that's in readme?). "Commit" writes to EEPROM.
"Revert" reboots the controller - same thing as pulling the USB plug and plugging it back.

Is it normal for FC to say "wrote zero bytes" when I commit to eeprom? And how come even though FC is registering keypresses in layout and elsewhere, I can't get output outside of FC?

Okay update.

On kmnov's and Darkcruix's recommendation, I stuffed a bit of folded up plastic between the pcb and the edge connector and this seems to be the way to go. Even though I had continuity, I guess the contacts gotta really be pushed up against one another to work.

So this seems to have fixed my shift and caps lock issue. Also, FC is now writing something other than zero bytes to the EEPROM when I commit, but I STILL cannot get output outside of flight controller no matter what I do.

[DMA]

Even though I had continuity, I guess the contacts gotta really be pushed up against one another to work.

It's likely that you pushed on the socket when continuity-tested. So when you tested it there was contact, but not when it was used.

So this seems to have fixed my shift and caps lock issue. Also, FC is now writing something other than zero bytes to the EEPROM when I commit

That's because you actually change stuff.

As for "can't see keypresses" - check that you have layout correct and it has letters on _base_ layer. Setup mode gives you matrix coordinates. They are transformed by layout to actual USB scancodes.

[PancakeMSTR]

As for "can't see keypresses" - check that you have layout correct and it has letters on _base_ layer. Setup mode gives you matrix coordinates. They are transformed by layout to actual USB scancodes.

Right, and I can only get Flight Controller to see keypresses as matrix coordinates, not characters, regardless of what I've done in layout editor.

By _base_ layer, do you mean Layer 0? Cause I don't have anything "base" in layout editor. See this screenshot I took.

When I unclick "setup", such that it isn't yellow anymore, I get absolutely no output, in Flightcontroller or otherwise.

[DMA]

Ah. go to globals.h and change NOT_A_KEYBOARD back to zero.

[PancakeMSTR]

Ah. go to globals.h and change NOT_A_KEYBOARD back to zero.

Well, I was certain that would do it, but unfortunately no dice. For reference, I rebuilt both the bootloader and the 8x24 project in PSoC after I made this change, then reflashed the Cypress. Didn't make any difference, setup mode still only shows matrix indexes, while keypresses with setup mode off give no response.

I don't know if you've been keeping up with my posts but I wanted to make sure that you knew that I had removed C41, C42, and R5 to use the three auxiliary columns on 15.[2,3,4]. Would that make a difference?

[DMA]

I don't know if you've been keeping up with my posts but I wanted to make sure that you knew that I had removed C41, C42, and R5 to use the three auxiliary columns on 15.[2,3,4]. Would that make a difference?

Nope. That will un-zero columns mapped to those pins, but that's it.

At this point I would recommend doing it from scratch with freshly downloaded copy of the repo, and not cutting corners. Like, if readme says you should plan your pinout - you go and plan your fucking pinout.
It should match the picture in the repo, but it should match your physical wires, too - second being more important.

The EEPROM configuration should be good (as in "will contain bytes at the same positions for same settings"). Everything else - redownload, reexamine, set config.h to match your settings.

Beware, new repo changes locations of pins that must be Vbus and GND - because I couldn't find enough pins without capacitors on them and had to move things around.

PS: I'm pretty sure it's some change in code as opposed to hardware - but I'm not going to conduct git diff classes today. If you don't know what diff is - go from the start. If you do - git pull; git diff should tell you the difference between golden copy and yours.

[PancakeMSTR]

Okay I'm gonna start fresh on a different computer. It's the only thing I can think to try, other than trying a new Cypress.

Btw I've quadruple checked the pins, and I'm using the source from since you most recently updated the pins. I'll try from scratch anyway though, can't think of anything else to do.

[DMA]

Computer is not a part of the problem, that's one thing I can guarantee (FC is much fussier than HID driver, if it works - the USB device part definitely works). Delete the CommonSense directory, download from github, change config.h and pins to match your physical layout, recompile, reflash.

[PancakeMSTR]

Computer is not a part of the problem, that's one thing I can guarantee (FC is much fussier than HID driver, if it works - the USB device part definitely works). Delete the CommonSense directory, download from github, change config.h and pins to match your physical layout, recompile, reflash.

Okay so here are the steps I've taken and the symptoms I'm getting:

- Downloaded the source from github today (specifically, I cloned it to my server's share directory), since your commit yesterday.

- Recompiled, Reflashed. To be fair, all I modified was the config.h file, setting the columns (23) and rows (4) and setting the switch type to "BEAMSPRING". I didn't touch the pinout, even though it's slightly different from mine with respect to how the rows and columns are wired up.

- Started FC (with the micro USB end of the Cypress plugged in now).

- Set and applied minimum thresholds.

- Now here's where I narrowed down a couple different behaviors:

- If I upload to EEPROM with "SETUP" yellow, I get absolutely nothing from the keyboard outside of FC.

- On the other hand, if I upload to EEPROM with "SETUP" grey, then close flight controller, I do get output from the keyboard, for example on a google chrome tab. All it seems to be doing are spamming keys, though if I press the "Q" key, which I've mapped to output "Q", it spams "Q", so there's that.

- I would consider this a start, except that this only lasts as long as the keyboard/cypress is plugged in. If I unplug the Cypress and plug it back in (only considering the micro USB side), I'm back to no output.

[DMA]

- On the other hand, if I upload to EEPROM with "SETUP" grey, then close flight controller, I do get output from the keyboard, for example on a google chrome tab. All it seems to be doing are spamming keys, though if I press the "Q" key, which I've mapped to output "Q", it spams "Q", so there's that.

So, "setup" being yellow, controller outputs keypresses via debug channel. That's normal. To get it to send data as keyboard, you either click "setup" so it's grey, or exit FC.
The spam means your readings are unstable. Go to hardware settings, reset charge/discharge to what's recommended. If it's still a problem - look for the floating pieces of ground. Doubly so if you press one key and another lights up.

- I would consider this a start, except that this only lasts as long as the keyboard/cypress is plugged in. If I unplug the Cypress and plug it back in (only considering the micro USB side), I'm back to no output.

If you unplug the controller, plug it back and it behaves differently from when it was plugged - you didn't commit your latest changes to EEPROM. README.md goes in detail about this.

[PancakeMSTR]

So, "setup" being yellow, controller outputs keypresses via debug channel. That's normal. To get it to send data as keyboard, you either click "setup" so it's grey, or exit FC.
The spam means your readings are unstable. Go to hardware settings, reset charge/discharge to what's recommended. If it's still a problem - look for the floating pieces of ground. Doubly so if you press one key and another lights up.

I'll work on that, grounds, thresholds, charge/discharge delays. Would you mind clarifying what "recommended" means? Are you referring just to the settings stated in the readme?

If you unplug the controller, plug it back and it behaves differently from when it was plugged - you didn't commit your latest changes to EEPROM. README.md goes in detail about this.

I absolutely committed my changes to EEPROM, at least in so far as I pressed the buttons to do so in FC. If you want, I will literally take a video of me doing an FC EEPROM commit, unplugging and replugging the cypress, then getting no output from pressing keys.

[darkcruix]

Apart from committing to EPROM, did you uodate prior (CTRL+U)?

[PancakeMSTR]

Apart from committing to EPROM, did you uodate prior (CTRL+U)?

I've tried it both ways, updating and not updating. Makes no difference as far as I can tell.

[DMA]

Apart from committing to EPROM, did you uodate prior (CTRL+U)?

I've tried it both ways, updating and not updating. Makes no difference as far as I can tell.

"Update" uploads the config to the controller, but if you pull the plug, changes disappear.
"Commit" saves whatever current config is, so when you pull the plug - it persists. It reports how many bytes were actually changed - which is not of much use to you, but it was for me at the time so it's there.

Recommended settings are.. let's say 20/180. They're in tooltips in FC. See README, the discharge delay can be arbitrarily long. Charge delay much less so. If you get it too short - your readouts will be low, if too long - EMI resistance suffers(and also readouts lower somewhat because charges leak out). If you _really_ want to tinker with charge delay - get a scope^W^W^W - find the point where readouts stop raising and stick to that point.

I also start suspecting that you have a mac or linux and your windows machine is a VM (although your screenshots seem to come from a real machine).
If this is the case - control channel and actual keyboard are DIFFERENT USB DEVICES. Make sure both are plumbed to the same VM.
Or connect to your physical machine and try to type. FC is not needed on that machine, just make extra sure you have a layout in EEPROM with at least 1 key mapped to something alphanumeric.

If you made all this and it still doesn't work - shoot me a PM, I can arrange a remote debugging session. I'm officially out of ideas.

[PancakeMSTR]

PMed

[DMA]

Found a thing commented out that should not have been commented out.
Would manifest as keyboard not turning "Output" green and not emitting anything if just plugged in, with FC not being connected.

PancakeMSTR - that likely fixes your problem.

[PancakeMSTR]

Found a thing commented out that should not have been commented out.
Would manifest as keyboard not turning "Output" green and not emitting anything if just plugged in, with FC not being connected.

PancakeMSTR - that likely fixes your problem.

I'll try it when I get home and get back to you with the results.

I'll probably have to download the new source right?