Help troubleshooting a hand wired matrix.

[Moralless]

So I recently tried to clean up my custom keyboard by desoldering all the wires (but leaving the diodes) and replacing those wires with thinner ones. Previously everything was working fine but I was more worried about the longterm longevity of the board so I decided to rewire everything anyway. I've used the same controller (with no burns) but different firmware (I used the one written by hasu, but had to switch the order of the pins I used since I rerouted everything). However, when I compiled the new code and started typing nothing is detected by Aqua key tester except for the grv, 1, 2, 3 and 4.
This is what happens:
When I press grv it says that I've pressed grv + tab
When I press 1 it says that I also press grv + tab
When I press 2 it say I pressed LCTRL  (I placed the LCTRL where caps lock usually is
When I press 3 it says I pressed LShift
When I press 4 it say I pressed the LWIN key.

Here are the before and after pics:

Before:

After:


The problem is, I don't know if this is a hardware problem or software since I know in the after pic I connected the columns to the controller from the opposite side relative to the before pic, but I don't know how to account for this change in the code (or if I can). I've only just finished soldering this so I have yet to try anything but would like some advice on which parts I should focus on. Could this be caused by shorts?

[Neebio]

This sounds like you might have rows/columns swapped.  I'm no expert, and have not wired up a keyboard myself before, but I would look either into the firmware to see if you can define what pins the rows and columns are on (so the controller reads them correctly) or you may have wired the rows/columns to the wrong pins on the controller.

And the usual troubleshooting: grab a multimeter and start doing tests to make sure you don't have shorts in your matrix anywhere, or breaks in your wires, or bad solder joints, etc.

[OverKill]

Yes you could have the rows/columns swapped in the software, or you could have a short somewhere from a wrong/row/column to another row/column. What I would recommend is to start with 1 row/column and get that to work first. Change the software so that you use all the keys from that one row/column and nothing else. If that does not work swap the rows/columns in software and see if that fixes the issue. After you get the initial one to work you keep adding rows/columns 1 at a time until you find the culprit. When I did mine I had some switches wired up wrong and some software issues as well. The best way to figure out whether it is software or soldering/short would be to use the above method. There may be better methods that are out there but that is the one I use and it is a little time consuming but once you get the hang of it, it goes very quickly. Good luck!

[Oobly]

Also check that the diode orientation is correct for the particular firmware you're using.

[Moralless]

Also check that the diode orientation is correct for the particular firmware you're using.

Could you tell me how? I don't really understand how to interpret the diode interpretation in terms of columns/rows for the firmware. Currently I'm thinking of the orientation as the direction of the columns e.g.

     D1    ->    D2    ->     D3    ->... (Row 0)
|Column 0| Column 1| Column 2| ....
 

[dorkvader]

the line on the diode should be closest to the square pad, but since some people soldered them backwards (especially on the left hand where they are opposite the normal orientation for a cherry KB) you can get a modified firmware that's set up to account for this.

[Oobly]

Also check that the diode orientation is correct for the particular firmware you're using.

Could you tell me how? I don't really understand how to interpret the diode interpretation in terms of columns/rows for the firmware. Currently I'm thinking of the orientation as the direction of the columns e.g.

     D1    ->    D2    ->     D3    ->... (Row 0)
|Column 0| Column 1| Column 2| ....

It's all about the current direction, whether the firmware drives the columns and senses the rows or drives the rows and senses the columns and whether logical "on" is "high" (+3.3 or 5v) or "low" (gnd, 0v). The firmware can be set up for any combination of these, so a matrix can be wired in one of four different ways.

Find out what matrix layout Hasu's firmware expects and then make it like that. Or use a different firmware that matches your matrix wiring. Or adjust the firmware source code of any firmware to match.

[Moralless]

Also check that the diode orientation is correct for the particular firmware you're using.

Could you tell me how? I don't really understand how to interpret the diode interpretation in terms of columns/rows for the firmware. Currently I'm thinking of the orientation as the direction of the columns e.g.

     D1    ->    D2    ->     D3    ->... (Row 0)
|Column 0| Column 1| Column 2| ....

It's all about the current direction, whether the firmware drives the columns and senses the rows or drives the rows and senses the columns and whether logical "on" is "high" (+3.3 or 5v) or "low" (gnd, 0v). The firmware can be set up for any combination of these, so a matrix can be wired in one of four different ways.

Find out what matrix layout Hasu's firmware expects and then make it like that. Or use a different firmware that matches your matrix wiring. Or adjust the firmware source code of any firmware to match.

Thanks for the tip, but I ended up figuring it out now and am currently using it to type this response .