Keyboard has started sending inputs on its own

[ameyp]

I've been using a kint with a teensy 3.6 on an Advantage 500 for a few years now (pretty much starting a few months after you made this available) and haven't had any issues till today. Out of nowhere, the keyboard has started randomly inputting characters. The problem seems isolated to roughly the top half of the keyboard based on the characters I see appear, so it's the function row, numbers row and QWERTY row, both halves.

I opened it up and blew away any dirt/crumbs that had accumulated, but that didn't fix it. My soldering work from back then wasn't perfect, but I don't see any bridged pins. Any ideas what might be causing this? Could the controller just be dying?

[stapelberg]

Sorry to hear about your trouble with this build.

Typical causes for ghost key presses are indeed faulty soldering joints. It might be worth just going over all (most?) of your solidering joints.

Aside from soldering joints, another known aging issue is that individual key switches start bouncing more and more over time. This will typically manifest itself with one specific key first, not a whole range of keys.

Maybe https://github.com/kinx-project/kint/issues/16 is helpful to track down the issue more (to an individual GPIO line).

[ameyp]

Thanks, I had a wonderful couple of years with the keyboard thanks to your work here, and would love a couple more!

I did take a look at that issue, but had trouble figuring out which ROW_ nets mapped to physical rows on the board. I also took a look at the schematic PDF, but couldn't see that mapping there either.

Also, since my keys appear to be failing closed rather than open (aka 20-30 keypress events are being sent without any key being pressed) my intuition says that something is probably shorted. Is this conclusion correct? If so, how would I verify this, would checking for connectivity between the pins I discover using kicad and the GND pin be the way to go?

[stapelberg]

I did take a look at that issue, but had trouble figuring out which ROW_ nets mapped to physical rows on the board. I also took a look at the schematic PDF, but couldn't see that mapping there either.

Can you enable QMK’s debug logging as mentioned in the issue? Then, it will print the key matrix on every key press, which should allow you to track down which column(s) and/or row(s) are affected.

Also, since my keys appear to be failing closed rather than open (aka 20-30 keypress events are being sent without any key being pressed) my intuition says that something is probably shorted. Is this conclusion correct?

If something was shorted, you would probably not get key presses at all, or get key presses permanently. My guess is that some connection is “bouncing”.

If so, how would I verify this, would checking for connectivity between the pins I discover using kicad and the GND pin be the way to go?

No, I don’t think that would help, as I don’t think anything is shorted to GND. As I said, in that case I would expect no key press to be generated at all.

Instead, you should be looking for connectivity that only works if you place your multimeter “just right”. But, as I said, it might be easier to identify the affected columns/rows and proactively re-solder the affected soldering joints instead of trying to use a multimeter.

[ameyp]

I enabled debug mode, but only ran into this issue once after, and that was while the keyboard was connected to a PC without qmk on it. I cleaned out both key-wells (there was dog fur in them) and haven't run into the problem since, so I'm closing this issue. If I run into it again and can get console output (I'm leaving debug enabled) I'll re-open this. Thanks again for your help and for creating this awesome pcb!