CommonSense: matrix LCR meter with a HID interface

[DMA]

Are you also experiencing EMI while not scanning?

Dunno, I'm constantly scanning Except in USB suspend, but even there I scan about 10 times per second.

[__red__]

I'll check if it's possible to run cypress stuff using VirtualBox when I have time

This is how I run it.

[tigpha]

Hi, I've wired the PSoC to the XT at long last. But the signals are very faint on the matrix monitor. Some of the rows look quite dead, stuck at zero. Others appear to be sensing some low-level noise. Only one column registers a few key presses, and even so, these don't go high, about 6 or 7.

The PCB was suspect to start with, quite a few areas of the board have black copper oxide under the solder resist layer. It could be that some traces are corroded to the point it is no longer conducting electricity at all. I must do a continuity check.

I have a second XT which looks in good shape, no corrosion, but I don't have a way to test it first before modifying it, to check it's a known-good specimen,

DMA, __red__, please can you help me with suggestions how to debug the hardware? Even a list of basic things to check first is useful, such as continuity checks etc., I may have missed something very obvious. It would be useful information to share.

wire connections to the PSoC

solder-PSoC-pcb.jpeg (814.99 KiB) Viewed 7737 times

wire connections to the XT keyboard logic board

solder-XT-pcb.jpeg (1.26 MiB) Viewed 7737 times

Wire looms between keyboard logic pcb and the PSoC pcb

Connecting-wires.jpeg (785.18 KiB) Viewed 7737 times

[DMA]

When I said "I tested it with 2 ft wires and it worked" I didn't mean it to be a recommendation. It should work though.
You don't have a scope, I presume?

obvious things:
1) check that you don't use pins with capacitors. They're marked * on the picture with kit pin descriptions.
2) check there's no shorts. Between PCB and the metal cage, too.

Once this is taken care of -
open the assembly, get access to the PCB. Leave the PCB on the back plate. run matrix monitor. Grasp the row wire you see responses from, press your other hands' finger against contact plates on the PCB, observe. You should see pretty strong signal.
If that doesn't work - touch column wires with the same fingers you used in previous step. Don't short row to column - you won't fry anything but the results may surprise you as I only read lower 8 bits from the ADC and god only knows what you'll see.
Or you may swap last 2 steps - or even desolder the controller from the board and just touch the pin pads to make sure the controller is OK.

[tigpha]

When I said "I tested it with 2 ft wires and it worked" I didn't mean it to be a recommendation. It should work though.

Hehehe The wire looms are 20cm (8 inches) long. Since rewiring seems unavoidable, I'll trim much shorter.

As for a scope, I'd love to get one, but for the moment I'm experimenting to see how far a complete neophyte beginner (i.e. me!) can reach with very basic tools and understanding. A Rigol DSO is on my birthday presents wish list.

obvious things:
1) check that you don't use pins with capacitors. They're marked * on the picture with kit pin descriptions.
2) check there's no shorts. Between PCB and the metal cage, too.

Point 1) Oops. I can already see I made a mistake. Does this rule apply to sensing lines on rows only, or in general just to be sure? I have to avoid P15_4 and P15_3 for the rows, and P15_2 for the columns.

This begs the question, how to remap the pins? RTFM no doubt, regarding PSoC Creator IDE, but a recipe how-to describing pin remapping would be a big help, please.

Point 2) Continuity and short probing is on my to-do list, definitely.

Once this is taken care of -
open the assembly, get access to the PCB. Leave the PCB on the back plate. run matrix monitor. Grasp the row wire you see responses from, press your other hands' finger against contact plates on the PCB, observe. You should see pretty strong signal.
If that doesn't work - touch column wires with the same fingers you used in previous step. Don't short row to column - you won't fry anything but the results may surprise you as I only read lower 8 bits from the ADC and god only knows what you'll see.
Or you may swap last 2 steps - or even desolder the controller from the board and just touch the pin pads to make sure the controller is OK.

Thanks DMA, all this is very helpful advice. I deeply appreciate your time and patience.

[DMA]

A Rigol DSO is on my birthday presents wish list.

I don't know about DSO, but 4 channels are _very_ useful. 1 for trigger, 3 for signals. Although I probably used mine for like 40 hours now. Don't know if that's $400 well-spent. Allows to see things much better though.

Point 1) Oops. I can already see I made a mistake. Does this rule apply to sensing lines on rows only, or in general just to be sure? I have to avoid P15_4 and P15_3 for the rows, and P15_2 for the columns.

Actually, current github version has XT 8x12 matrix and pretty sensible pinout, guaranteed working (I'm using it on my daily driver). You can just reuse it.

This begs the question, how to remap the pins? RTFM no doubt, regarding PSoC Creator IDE, but a recipe how-to describing pin remapping would be a big help, please.

Look at "Pins" in the PSoC window with sources, near the top. the only trick there is that columns must be aligned to the bottom - "cols[23] is the last column in the matrix", not "cols[0] is the first column"

[tigpha]

I probably used mine for like 40 hours now. Don't know if that's $400 well-spent. Allows to see things much better though.

Better than not seeing at all, that's invaluable!

current github version has XT 8x12 matrix and pretty sensible pinout, guaranteed working (I'm using it on my daily driver). You can just reuse it.

Big thanks! That's now Plan A. After continuity and shorts tests...

[DMA]

Big thanks! That's now Plan A. After continuity and shorts tests...

Just desolder the controller and grab one row and columns one by one.
You'll do two things by that:
a) verify mapping - you'll see which wire is which column IN REALTIME.
b) verify hardware isn't shot (though it shouldn't be, because you're getting SOME readings).

[DMA]

ADC resolution, charge and discharge delay, and debouncing buffer length are now configurable from FlightController.

In other news, fried 2 proto kits today by connecting to USB-C of a macbook pro connected to a power supply, using USB-C-to-female-USB-A which came with google pixel + the usual micro-USB cable.
Luckily I only connected my xtant when mac was on battery. For some reason this was safe.
Fried second one because oh well, that probably was static electricity first time. Suuuure.

[wcass]

That proto board has a fuse. I thought that was supposed to prevent permanent damage in an over-current situation.

[DMA]

That proto board has a fuse. I thought that was supposed to prevent permanent damage in an over-current situation.

Looks like this was an overvoltage situation
I don't know how much there was - could be 9, 12 or 20V. But I now have 2 dead kits on my hands.

OTOH those weren't the last ones - one in the xtant miraculously survived (because the macbook wasn't plugged in) and I have 2 more unused. It's just that feeling of "wtf, I killed 2 devices over some minor incompatibility!" and the fact I threw good money after bad.

Anyway. If I run out - I'll probably order couple of BT protoboards and make a BLUETOOTH MODEL F.

[hansichen]

Hi guys. I'd like to test this controller as a replacement of the xwhatsit controller. Getting the CY8CKIT-059 controller is an easy thing but do you guys know which edge connector the xwhatsit uses to slip onto the pcb? I'd like to get such a part and then solder from this connector with wires onto the CY8CKIT-059 controller so that I don't damage/modify the pcb.

[andrewjoy]

Its something like this https://www.ebay.co.uk/itm/Card-Edge-Co ... SwUwFaQ3bU

but i don't know the exact spacing or number of pins sorry

If i can find my spare controller tonight i will have a look for you

I also that there was a BOM for his controller somewhere , take a look at that.

But honestly you can just solder it and remove it later if you need to , as long as you use plenty of flux and some solder wick you will get it clean at the end , will just take time.

[__red__]

So, the unpopular position:

You can't buy the correct edge-connector. You can buy an edge-connector that is close - but there is no cigar.

The problem is that all modern edge-connectors are for standard width PCBs, the keyboard PCBs you're trying to interface to are much thinner.

Now, in every case that I know of, the pins on the top and bottom directly map so it still will _work_ from a connectivity standpoint, but it made me nervous enough from a reliability point of view that I directly soldered to the fingers.

I'll be posting something on the subject this evening I hope - just getting the photos set up.

[andrewjoy]

You could try pushing the pins down on the connector side , depending on how they are done ( like a cartridge slot on consoles etc) you should be able to tighten them up a bit

[DMA]

Hi guys. I'd like to test this controller as a replacement of the xwhatsit controller. Getting the CY8CKIT-059 controller is an easy thing but do you guys know which edge connector the xwhatsit uses to slip onto the pcb? I'd like to get such a part and then solder from this connector with wires onto the CY8CKIT-059 controller so that I don't damage/modify the pcb.

What __red__ says. Solder it on.
The connector you're looking for is 2x30pin 3.96mm pin spacing. The problem is they all are made with 1.6mm-thick board in mind (or 1.8? can't remember exactly). And the board you have is 0.8mm thick.

[hansichen]

Thanks guys, I think I'll look a bit more into the documentation before I decide to solder onto the pcb

[wcass]

Another idea that doesn't require soldering ... add a shim.

The original PCB is 0.8 mm and the connector wants 1.6 mm, so just add another 0.8 mm shim and stack it.

something like this:

Shim.png (6.48 KiB) Viewed 7498 times

You can get 3 of these from OshPark for $7.25 delivered. Select the option for "2 oz copper, 0.8mm thickness"
Gerber file is attached below.

[__red__]

Another idea that doesn't require soldering ... add a shim.

The original PCB is 0.8 mm and the connector wants 1.6 mm, so just add another 0.8 mm shim and stack it.

something like this:

Shim.png

You can get 3 of these from OshPark for $7.25 delivered. Select the option for "2 oz copper, 0.8mm thickness"
Gerber file is attached below.

Oh, that's nice wcass - bravo!

[hansichen]

Thanks for your effort, after looking for all the parts I decided that I'll try the solder way. As long as I don't fuck it up it shouldn't matter that I soldered onto the pcb so I should be fine and I have a way easier time to source all the parts for it.
Is there a recommended pinout on which pin of the xwhatsit configuration to solder on which pin of the CY8CKIT-059 controller? From what I've seen there were only beamspring convertions with a custom pcb in this thread which didn't give any clue in that regard.

[__red__]

Thanks for your effort, after looking for all the parts I decided that I'll try the solder way. As long as I don't fuck it up it shouldn't matter that I soldered onto the pcb so I should be fine and I have a way easier time to source all the parts for it.
Is there a recommended pinout on which pin of the xwhatsit configuration to solder on which pin of the CY8CKIT-059 controller? From what I've seen there were only beamspring convertions with a custom pcb in this thread which didn't give any clue in that regard.

If you are using the CY8CKIT controller then that has nothing to do with xwhatsit at all. Completely different hardware, completely different software.

I actually owe a proper write-up to this forum, so give me a few and I'll try and get it knocked out.

[hansichen]

Ah sorry, I was asking about how to wire it up onto a normal beamspring pcb. On my pcb pins 2-6 are empty, 7-14 are columns, 15-16 empty, 17-25 columns, 27-30 rows. Pin 1 and 26 are connected which each other and they go around all of the pads, are these the grounding pins?

Code: Select all

Recommended pinout

    D0: P0[3]
    D1: P3[2]
    Rows: P0[0, 1, 5, 6, 7], P15[3, 4, 5]. Alternatively, P12 can be used to free more analog-capable pins, but watch for ExpHdr pins.
    Cols: P1[0-7], P2[0, 2-7], P3[0, 1, 3-7], P15[0, 1, 2].
    P0[2], P0[4] to +5V, P0[3], P3[2] to the ground.

Whew. Hopefully you're done with soldering now.

If I look at the pinout on the controller on github I understand the rows and columns, connecting P0[2] and P0[4] to +5V and P0[3 and P3[2] to ground on the controller is clear too. I still have problems to understand what D0 and D1 is for? Is this the ground connection of the pcb and plate? If so I should be connect either way pcb-pin 1 or 26 to one of them and the plate to the other one. Is that correct or did I understand something wrong?

[__red__]

No, D0 and D1 are internal references, not pins numbers. They're actually mapped in software to (off the top of my head) P0[3] and P3[2]

[wcass]

This post will help ...
workshop-f7/commonsense-controller-bett ... ml#p392189

[hansichen]

Thanks for your help, I feel like such a noob. I wired the whole thing now and build the bootloader. Now I try to do the firmware. I opened the file and changed it to beamspring and then went into the pinout. There I find all the columns and rows and D0, BootPin, \USB:Dp\, \USB:Dm\, \ADC0:ExtVref\ and skveral ExpHdr things to configure. D0 is clear, D1 is not existent here and for the others I kept the standard config for now. When compiling it I get two errors now, first #include "globals.h" in line 10 of cyaplcallbacks.h is not found, even if that file should exist normally.
At the moment I can't find a thing that I overlooked so I'm wondering what went wrong.

[DMA]

Thanks for your help, I feel like such a noob. I wired the whole thing now and build the bootloader. Now I try to do the firmware. I opened the file and changed it to beamspring and then went into the pinout. There I find all the columns and rows and D0, BootPin, \USB:Dp\, \USB:Dm\, \ADC0:ExtVref\ and skveral ExpHdr things to configure. D0 is clear, D1 is not existent here and for the others I kept the standard config for now. When compiling it I get two errors now, first #include "globals.h" in line 10 of cyaplcallbacks.h is not found, even if that file should exist normally.
At the moment I can't find a thing that I overlooked so I'm wondering what went wrong.

How do you change it to beamspring?
should be "#define SWITCH_TYPE BEAMSPRING".
Also check that MATRIX_COLS and MATRIX_ROWS match your intended configuration.
Those should be the only changes.

D1 doesn't exist indeed - added a note to README.md
In general you're not supposed to touch anything except rows and cols (and may be ExpHdr if you want solenoid. By default ExpHdr is configured to blink the kit's LED on keypress)

[hansichen]

I went to /dma_core/globals.h in the PSoC Creator and changed #define SWITCH_TYPE BUCKLING SPRING to BEAMSPRING. If I see it correctly the board has 17 Columns and 4 Rows (This is the pcb printing: https://i.imgur.com/za0nt6X.png) and that's what I changed. After putting in the Rows and then building it with Ctrl + F5 I get this errors:
"prj-M0120: Build error: globals:h: No such file or directory" in file cyapicallbacks.h, line 10, col 21 and
"prj-M0120: Build error: The command 'arm-none-eabi-gcc.exe' failed with exit code '1'.

[DMA]

I went to /dma_core/globals.h in the PSoC Creator and changed #define SWITCH_TYPE BUCKLING SPRING to BEAMSPRING. If I see it correctly the board has 17 Columns and 4 Rows (This is the pcb printing: https://i.imgur.com/za0nt6X.png) and that's what I changed. After putting in the Rows and then building it with Ctrl + F5 I get this errors:
"prj-M0120: Build error: globals:h: No such file or directory" in file cyapicallbacks.h, line 10, col 21 and
"prj-M0120: Build error: The command 'arm-none-eabi-gcc.exe' failed with exit code '1'.

Please do a git pull (or just download the zip again). I found a bug which will lock up the firmware if there's no configuration and fixed it.
I've tested the build - it compiles with SWITCH_TYPE BEAMSPRING, so everything should be good.

One thing to check - what is the path to CommonSense directory? Is it free from spaces and non-latin characters? Is it a local path (starts with a letter, that is - like C:\Projects\CommonSense) ?

Update: try to compile without changing any files. If that doesn't work - the problem is most likely paths. If that works.. try one change at a time. I never encountered this behavior before.

[hansichen]

So I tested it several times today with several configs and the new and old zips. As a path I used C:\CommonSense\CommonSenseTest and I tried to compile everything without changing a thing. I still ended with the same Error codes as earlier.

[DMA]

So I tested it several times today with several configs and the new and old zips. As a path I used C:\CommonSense\CommonSenseTest and I tried to compile everything without changing a thing. I still ended with the same Error codes as earlier.

Mind if we do a teamviewer session? Just don't send sessionid and password here, use the private message